So Secure Sie Server auf Server

Wenn Benutzer und Administratoren von On-Premises-SharePoint eine Datei hochladen, wird diese entweder mit einem Antivirenprogramm eines Drittanbieters oder mit AMSI-kompatiblen Engines (wie beispielsweise Microsoft Defender) gescannt. Wenn die Datei diesen ersten Scan besteht, gilt sie als geprüft. Einmal sauber, immer sauber. Genau diese Annahme ist der Grund dafür, dass sich Malware- und Ransomware-Payloads unentdeckt im Repository einnisten können – manchmal über Jahre hinweg.

Microsoft sagt dies ganz offen: Der Malware-Schutz von SharePoint kann den Schaden begrenzen, dient jedoch nicht als einzige Verteidigungsmaßnahme.

In den Bereichen BFSI (Bankwesen, Finanzdienstleistungen und Versicherungen), Gesundheitswesen, öffentliche Verwaltung sowie OT (Operational Technology) oder kritische Infrastrukturen umfassen die gefährdeten Daten Compliance-Unterlagen, Patientenakten, Fallakten und technische Dokumentationen. All diese Daten befinden sich in einem Archiv, das von Jahr zu Jahr weiter wächst, während nichts zurückverfolgt wird, um den bereits vorhandenen Inhalt erneut zu überprüfen.

Im Folgenden geht es im Wesentlichen um drei Dinge: Wie funktioniert die Antivirenprüfung in SharePoint eigentlich, was wird dabei nicht abgedeckt und wie sollte eine mehrschichtige, wirksame Sicherheit für das SharePoint-Dateirepository aussehen?

Die Daten von Enlyft zur Technologieeinführung umfassen 256.295 Unternehmen, die derzeit Microsoft SharePoint einsetzen und aus verschiedenen Branchen stammen, darunter IT-Dienstleistungen, Bankwesen, Gesundheitswesen, Öl- und Gasindustrie sowie der öffentliche Sektor. Diese Unternehmen beschäftigen in der Regel 50 bis 200 Mitarbeiter und erzielen einen Umsatz von 1 Mio. bis 10 Mio. US-Dollar.

Gerade diese Größenordnung ist der Grund, warum Angreifer SharePoint-Repositorys ins Visier nehmen und als besonders lohnende Ziele betrachten.

Das soll keineswegs heißen, dass SharePoint seine Server nicht schützt oder die Dateisicherheit vernachlässigt. Laut der Dokumentation von Microsoft Server SharePoint Server in zwei mögliche Scan-Schnittstellen Server :

• VSAPI (Virus Scanning API) ist eine Schnittstelle zur Integration von Antivirenprogrammen in SharePoint, die es kompatiblen Antivirenprogrammen von Drittanbietern ermöglicht, Dokumente bei Vorgängen wie dem Hoch- und Herunterladen zu scannen.

• AMSI (Antimalware Scan Interface), ein Integrationsframework von Microsoft für Antimalware, das es SharePoint Server ermöglicht, Dateien zur Malware-Prüfung während unterstützter Inhaltsvorgänge an AMSI-kompatible Antiviren-Engines (wie beispielsweise Microsoft Defender) Server übermitteln.

Der Server kann sokonfiguriert werden, dass er VSAPI, AMSI oder den automatischen Modus verwendet. Unabhängig davon, welche Option eingestellt ist, wird eine Datei jeweils nur von einer Scan-Engine geprüft.

Das Scannen erfolgt ereignisgesteuert und wird ausgelöst, wenn Benutzer Dokumente hoch- oder herunterladen, nicht rückwirkend oder in regelmäßigen Abständen. Die Datei wird nur von einer einzigen Engine (der Microsoft Malware Protection Engine, allgemein bekannt als MpEngine.dll) überprüft.

Das Wichtigste auf einen Blick: Dateien werden beim Hoch- oder Herunterladen mit einer einzigen Engine gescannt, wobei die aktuellen Signaturen und Erkennungsfunktionen dieser Engine zum Einsatz kommen.

Dieser Ansatz ist nicht darauf ausgelegt, eine dateibasierte Bedrohung zu erkennen, die gezielt darauf ausgelegt ist, die Erkennungslogik dieser speziellen Engine zu umgehen. Insbesondere „Advanced Persistent Threats“ (APTs) nutzen oft genau diese Einschränkung aus und bleiben so über längere Zeiträume hinweg unentdeckt.

Diese Beharrlichkeit eröffnet Angreifern die Möglichkeit, vertrauenswürdige SharePoint-Inhalte für böswillige Zwecke zu missbrauchen. Es gibt bereits dokumentierte Angriffe, bei denen Angreifer kompromittierte SharePoint-Websites missbraucht haben, um Phishing-Dokumente und bösartige Links zu hosten.

Ein Zero-Day-Angriff wird beim Scan genauso als unbedenklich eingestuft wie eine saubere Datei, ganz einfach, weil es noch keine Scan-Engine gibt, die ihn erkennt. Und da SharePoint vorhandene Inhalte später nicht erneut scannt, wird eine Zero-Day-Datei, die am ersten Tag den Scan passiert, auch am zweihundertsten Tag nicht noch einmal überprüft – selbst wenn der Anbieter ein Signatur-Update veröffentlicht, das sie erkennen würde.

Unbekannte Bedrohungen folgen derselben Logik. Da ihnen keine Signatur zugeordnet ist, kann die statische Analyse (wie sie von Antiviren-Engines durchgeführt wird) die Bedrohung nicht erkennen.

Hinweis: Hierbei handelt es sich eher um Lücken im Funktionsumfang als um Fehler. Der native Virenschutz Server SharePoint Server wurde für punktuelle Überprüfungen an bestimmten Interaktionspunkten entwickelt und nicht dafür, ein wachsendes, versioniertes Repository kontinuierlich anhand einer sich ständig verändernden Bedrohungslandschaft neu zu validieren.

Im Juli 2025 gab Microsoft bekannt, dass eine Kette von Sicherheitslücken, die die Ausführung von Remote-Code ohne Authentifizierung ermöglicht, aktiv ausgenutzt wurde und lokale Server betraf: CVE-2025-49706, CVE-2025-49704, später kamen noch CVE-2025-53770 und CVE-2025-53771 hinzu. Für den Exploit waren weder Anmeldedaten noch eine Anmeldung erforderlich.

Microsoft hat die Sicherheitslücke daraufhin behoben, und die Exploit-Kette erhielt einen Namen: ToolShell.

Laut einer vom „Infosecurity Magazine“ zitierten Analyse von Eye Security wurden 396 kompromittierte Systeme in 145 Organisationen in 41 Ländern entdeckt. Am stärksten betroffen war der öffentliche Sektor, auf den 30 % der bestätigten Infektionen entfielen, wobei allein auf die USA 31 % der Gesamtzahl entfielen. Unabhängig davon berichtete die Shadowserver Foundation, dass mehr als 10.700 SharePoint-Instanzen weiterhin ungeschützt waren und von jedem erreicht werden konnten, der dieselbe Exploit-Kette einsetzte – selbst nachdem die Sicherheitslücke, durch die Hunderte von Organisationen kompromittiert wurden, öffentlich bekannt geworden war. Storm-2603, eine der Gruppen hinter dem Exploit, nutzte diese Sicherheitslücke für den Einsatz der Warlock-Ransomware.

Sobald sie sich Zugang verschafft hatten, nutzte Storm-2603 gestohlene Zugangsdaten und legitime Administrator-Tools, um sich quer durch die Systeme zu bewegen. Diese Bewegung löste keinen Alarm aus, da sie auf Tools zurückgriff, die dort eigentlich vorhanden sein sollten. Storm-2603 installierte Web-Shells und exfiltrierte wichtige Daten. Die Angreifer behielten ihren Zugriff auch nach der Behebung der Sicherheitslücke bei, da sie bereits die Schlüssel gestohlen hatten, die zur Fälschung gültiger Authentifizierungstoken erforderlich waren.

ToolShell basiert auf vier miteinander verketteten CVEs, wobei von Anfang an Mechanismen zur Umgehung von Patches integriert waren. Die CVEs CVE-2025-53770 und -53771 existieren gerade deshalb, weil die ursprünglichen Korrekturen für CVE-2025-49704 und -49706 umgangen werden konnten.

Entscheidend ist, dass sich ein Angreifer zweimal innerhalb weniger Wochen schneller an das gleiche Ziel angepasst hat als der Patch-Zyklus.

Statische Schutzmaßnahmen wie einzelne Antivirenprogramme, die eine Datei einmalig anhand der Signaturen eines einzigen Anbieters überprüfen, waren von vornherein nicht dafür konzipiert, eine serverseitige Exploit-Kette zu erkennen. Außerdem bieten sie keinen Schutz vor einem Angreifer, der nach der Veröffentlichung eines Patches mit einer Umgehungsmethode für diesen Patch zurückkehrt.

ToolShell verdeutlicht, wie ausgefeilt die Angriffe mittlerweile speziell auf SharePoint-Server abzielen. Es gibt keinen Grund anzunehmen, dass dies das letzte Mal war, dass ein solcher Angriff stattfand. Sind die Daten auf diesen Servern durch eine Lösung geschützt, die mit den Entwicklungen Schritt hält, oder durch einen Scan, der einmalig durchgeführt wird und dann als erledigt gilt?

Um fair zu sein: Bei ToolShell handelte es sich nicht um ein bösartiges Dokument, das einen Upload-Scan umgangen hatte. Aber die Web-Shell (spinstall0.aspx und ihre umbenannten Varianten), die die Angreifer platziert hatten? Das ist eine Datei. Sie befand sich auf dem Server, und ob sie als verdächtig markiert wurde, hing von denselben Einschränkungen ab, die zuvor beschrieben wurden: eine Engine, eine Überprüfung, zu einem einzigen Zeitpunkt.

Das ist der Zusammenhang, der diesen Vorfall mit der übergeordneten Argumentation verknüpft. Durch das Patchen wird speziell die ToolShell-Exploit-Kette geschlossen. Für die nächste, noch nicht gescannte Datei, die sich bereits in einem Repository befindet, hat dies keinerlei Auswirkungen.

All das spielt für Inhalte, die seit 2023 unberührt geblieben sind, keine große Rolle, es sei denn, sie werden tatsächlich gescannt.

Dies ist der Bereich, den die in SharePoint integrierte Antivirensoftware nicht abdecken kann: die wiederkehrende oder kontinuierliche Überprüfung gespeicherter Inhalte – einschließlich älterer Versionen, die im Versionsverlauf aufbewahrt werden – und nicht nur beim Hoch- oder Herunterladen. Echtzeit-, zeitgesteuerte und bedarfsgesteuerte erneute Scans schließen diese Lücke, indem sie Dateien regelmäßig überprüfen, sobald Datenbanken aktualisiert werden.

Jede dieser Schutzmaßnahmen für sich genommen schließt eine bestimmte, zuvor angesprochene Sicherheitslücke. Zusammen bilden sie jene mehrschichtige Verteidigung, auf die Microsoft in seiner eigenen Dokumentation hinweist, wenn es heißt, dass der integrierte Virenschutz nicht als alleinige Verteidigungsmaßnahme gedacht ist.

MetaDefender Storage Security lässt sich über verschiedene Modellebereitstellen: physische Server für direkte Hardware-Installationen, Virtualisierungsplattformen (kompatibel mit VMware, Hyper-V und XenServer), IaaS (Infrastructure as a Service) von großen Cloud-Anbietern oder über containerisierte Bereitstellungen in Kubernetes-Clustern.

Diese Checkliste basiert auf den Leitlinien der CISA zum ToolShell-Exploit.

1. Überprüfen Sie den Status des Patches.

Für alle ausgenutzten CVEs sind Sicherheitsupdates verfügbar, doch nicht gepatchte Server sind weiterhin der Gefahr durch ToolShell ausgesetzt. Installieren Sie die Sicherheitsupdates von Microsoft für alle betroffenen Server .

2. Überprüfen Sie, ob AMSI konfiguriert ist.

Ein implementiertes, aber falsch konfiguriertes AMSI hinterlässt dieselbe Sicherheitslücke wie gar kein AMSI. Stellen Sie sicher, dass die AMSI-Integration aktiviert ist und auf jedem SharePoint-Server eine Antivirenlösung installiert ist.

3. ASP.NET-Maschinenschlüssel rotieren

Mit gestohlenen Maschinenschlüsseln können Angreifer auch nach der Installation eines Patches für den Server gültige Authentifizierungstoken fälschen. Durch das Installieren eines Patches allein werden bereits gestohlene Schlüssel nicht ungültig. Wechseln Sie die Maschinenschlüssel, installieren Sie das Sicherheitsupdate und wechseln Sie anschließend die Maschinenschlüssel erneut. Starten Sie IIS nach jedem Schlüsselwechsel mit „iisreset.exe“ neu, um bösartige Einträge aus den Dateien „applicationHost.config“ und „web.config“ zu entfernen.

4. Suchen Sie manuell nach Anzeichen einer früheren Kompromittierung.

Die CISA weist darauf hin, dass die in dieser Kampagne verwendeten .dll-Payloads dazu genutzt werden können, Systemschlüssel abzugreifen. Durch das Installieren von Patches wird die bereits auf dem Server abgesetzte Payload nicht entfernt. Überprüfen Sie Systeme und bestimmte Dateien auf IOCs (Indicators of Compromise) und nicht nur auf die Sicherheitslücke selbst.

5. Überprüfen Sie, ob es Versionen gibt, deren Lebensdauer oder Support abgelaufen ist.

Einige SharePoint-Instanzen haben das Ende ihres Lebenszyklus (EOL) erreicht und erhalten keine weiteren Sicherheitsupdates mehr, unabhängig davon, ob sie tatsächlich ausgenutzt werden. Überprüfen Sie, ob die in Ihrem Unternehmen verwendeten Versionen noch unterstützt werden. Ist dies nicht der Fall, ergreifen Sie die erforderlichen Maßnahmen.

6. Protokolle auf bekannte Indikatoren überprüfen

Die CISA hat bestimmte Anfragemuster und IP-Adressen identifiziert, die mit dieser Kampagne in Verbindung stehen. Durchsuchen Sie die Protokolle nach Anfragen, die den CISA-Angaben entsprechen.

7. Überprüfen Sie die Administrator- und Layout-Berechtigungen.

Um das Ausmaß des Schadens zu begrenzen, überprüfen Sie, wer über Layout- und Verwaltungsberechtigungen in SharePoint verfügt, und entziehen Sie Zugriffsrechte, die nicht aktiv benötigt werden.

8. Prüfen Sie, was bereits gespeichert ist, und nicht nur, was derzeit sichtbar ist

Alle oben genannten Punkte beziehen sich auf die Exploit-Kette selbst. Keiner davon betrifft Inhalte, die sich bereits in Dokumentbibliotheken befinden, einschließlich Dateien, die vor der Veröffentlichung dieser Patches erstellt wurden.

Stellen Sie fest, ob vorhandene Repository-Inhalte seit den entsprechenden Patches und Signatur-Updates erneut gescannt wurden oder ob sie noch immer das ursprüngliche, möglicherweise veraltete Scan-Ergebnis aufweisen.