Die bekannte SharePoint-Sicherheitslücke ToolShell wird zunehmend von Ransomware-Akteuren ausgenutzt. Jüngst wurde eine neue Variante der Open-Source-Ransomware Mauri870 entdeckt, die über PowerShell-Skripte auf verwundbaren Servern eingeschleust wird. Sicherheitsforscher sprechen von gezielten Versuchen, Schutzmechanismen zu umgehen und Systeme zu verschlüsseln – mit konkreten Lösegeldforderungen im Gepäck.

Was bedeutet das für IT-Abteilungen, die SharePoint noch On-Premises betreiben? Und warum reicht reines Patchen nicht aus, um sich gegen die Angriffe zu schützen? Im Interview mit IT Administrator erklärt Bitdefender-Experte Martin Zugec, wie Unternehmen ihre externen Angriffsflächen besser absichern können, welche Rolle MachineKey-Rotation und Netzsegmentierung spielen – und warum gerade kleinere Teams von Managed Detection & Response profitieren könnten.

IT-Administrator: Herr Zugec, was sollten Admins aus dieser Sicherheitslücke mitnehmen – vor allem, wenn sie SharePoint-Server noch On-Premises betreiben?

Martin Zugec: Zunächst sollten Administratoren davon ausgehen, dass Hacker ihre dem Internet exponierten SharePoint-Server kompromittiert haben. Alle Dienste mit Anschluss an das Internet müssen daher auf der Prioritätenliste der IT-Abwehr ganz oben stehen. Niemand kann sich allein auf die Ergebnisse einer Bestandsaufnahme der internen Assets verlassen, sondern sollte spätestens jetzt auch die externen Angriffsoberflächen im Blick haben. External Attack Surface Management (EASM) oder ähnliche Technologien helfen hierbei. Dabei lässt sich die Gefahr nicht unterschätzen: Denn für die Hacker ist die initiale Exekution von Remote Code oft nur der Auftakt für schwerwiegendere Attacken wie etwa Ransomware.

Für welche Szenarien halten Sie den Betrieb von SharePoint On-Premises noch für vertretbar – oder ist der Umstieg auf Microsoft 365 aus Sicherheitssicht der bessere Weg?

Microsoft 365 nimmt belastenden IT-Sicherheitsdruck von den Verantwortlichen. Dennoch können Vorgaben zu Compliance, Datenresidenz oder spezifische Anforderungen eines Unternehmens sich unter Umständen mit einem On-Premises-SharePoint besser erfüllen. Ein lokal implementiertes SharePoint verlangt aber deutlich höhere interne Investitionen in die Sicherheit und in die Überwachung.

Wie realistisch ist es aus Ihrer Sicht, dass IT-Abteilungen Patch-Zyklen in weniger als 24 Stunden umsetzen, wenn PoC-Code so schnell kursiert? Was wäre ein praktikabler Ansatz?

Patch-Zyklen innerhalb von weniger als 24 Stunden sind für viele IT-Teams nicht realistisch. Machbar ist dies erst durch ein robust automatisiertes und priorisiertes Patching. Ebenso wichtig für eine Abwehr ist eine umfassende Endpoint Detection and Response (EDR) oder Extended Detection and Response (XDR), die anomales Verhalten von IT-Assets entdeckt. Dazu sollte das Netzwerk streng segmentiert sein, um die Folgen eines Exploits einzudämmen. Dazu kommt es nun noch entscheidend darauf an, das Wichtigste zuerst zu tun: Zuerst zu schützen sind Dienste mit Internetkonnektivität. Oder Schwachstellen mit einem hohen CVSS-Wert. Die Faustregel lautet: Ab einem Wert von 8 und höher sollte man eingreifen. Zudem sollten sich Administratoren fragen, ob die Lücken eine Remote Code Execution (RCE) ermöglichen oder eine beliebte Software mit einer großen Nutzerbasis betreffen.

Der Exploit umgeht frühere Patches – was können Admins tun, um sich nicht in falscher Sicherheit zu wiegen, nur weil ein Update installiert ist?

Administratoren müssen sich darüber im Klaren sein, dass Patching allein in diesem Fall nicht ausreicht. Vor allem müssen sie unmittelbar ihre ASP.NET Machine Keys rotieren und die AMSI-Integration verifizieren. In der Folge müssen sie im Weiteren nach besonderen, nach einem Exploit auftretenden Indikatoren für eine Kompromittierung Ausschau halten. Denn oft halten die Angreifer einen persistenten Zugang aufrecht. Aktuell sollten IT-Sicherheitsverantwortliche unbedingt ausführbare Prozessketten über w3wp.exe -> cmd -> powershell encodedcommand sowie das Anlegen verdächtiger .aspx-Dateien beobachten: Solche Vorgänge sind deutliche Hinweise auf eine Attacke.

Was lässt sich über die Angriffsstrategie der ToolShell-Kampagne sagen? Welche typischen Merkmale oder Muster zeichnen solche Exploit-Ketten aus Ihrer Sicht aus?

Die Hintermänner der ToolShell-Kampagne verfolgen eine opportunistische Strategie: Das heißt sie suchen nach leichten Zielen, bei denen sie die bekanntgegebene Schwachstelle vorfinden. Unternehmensgröße, Branche oder Region des Netzes spielen keine Rolle für die Hacker. Die leichte Beute ist das Ziel. Die Cyberkriminellen führen unauthentifiziert Remote Code aus, um Maschinenschlüssel zu stehlen und so einen persistenten Zugang durch gefälschten Payload zu erlangen. Damit schaffen sie sich einen Brückenkopf für weitere, gefährlichere Angriffe wie etwa Ransomware. Dies ist ein typisches Angriffsmuster für Angriffe in diesem Jahr. Bemerkenswert auch das Tempo: Hacker haben sehr schnell die Proof-of-Concept- (PoC)-Codes für ihre Aktionen vorbereitet. Daher ist schon innerhalb weniger Wochen oder in den nächsten Monaten eine Welle an Angriffen zu erwarten.

Inwieweit beobachten Sie den Missbrauch von Funktionen zur dynamischen Codeausführung oder Systemreflexion in vergleichbaren Angriffen – und gibt es hier wiederkehrende Techniken?

Das ist ein typisches Vorgehen für derartige Attacken. Dadurch können Angreifer Sicherheitskontrollen umgehen, auf interne oder nicht öffentliche Funktionen wie GetApplicationConfig zugreifen und dann sensible Daten ohne einen direkten Zugriff auf das Dateisystem exfiltrieren.

Die Rotation der MachineKeys wird oft vergessen – was sind hier aus Ihrer Sicht die besten Wege, diesen Schritt zuverlässig in die Betriebsprozesse zu integrieren?

Die Notwendigkeit, Maschine Keys zu rotieren und dies zu überprüfen, zeigt, wie wichtig es ist, Schwachstellenbeschreibungen genau zu lesen und tatsächlich zu verstehen, wie Hacker eine einzelne Lücke auszunutzen. Patches mechanisch anzuwenden, genügt oft nicht. Unter Umständen sind noch weitere Schritte erforderlich. Um die Gefahr einzudämmen, sollten Administratoren den Instruktionen genau folgen und sich vergewissern, dass alle notwendigen Schritte tatsächlich wie erwartet wirksam sind. In diesem Fall heißt es konkret: Nach dem Patchen oder dem Aktivieren von AMSI ist es entscheidend für ein vollständiges Schließen der Lücke, die ASP.NET MachineKey Werte (ValidationKey und DecryptionKey) über alle Sharepoint-Server hinweg zu wechseln. Erst dieses gründliche Vorgehen devalidiert alle kryptographischen Keys, die Hacker kompromittiert haben könnten. Möglich ist das in Sharepont über Central Administration: Admins navigieren zu Monitoring > Review job definition, then locate and run the "Machine Key Rotation Job.". Dann erfolgt der Neustart (Restart IIS) und das Ausführen von iisreset.exe auf allen SharePoint-Servern. Das Kleingedruckte zu lesen, ist immer eine Voraussetzung, um Lücken wirklich zu schließen.

Welche Bedeutung hat Netzsegmentierung bei der Abwehr moderner Exploit-Ketten, und warum wird dieses Prinzip in der Praxis oft zu wenig umgesetzt?

Netzwerke intern zu segmentieren, schafft zusätzliche Schutzwälle gegen Angriffe, die Software-Schwachstellen in Edge-Geräten ausnutzen. Diese Lücken nutzen Hacker mit immer größerer Geschwindigkeit aus. Brute-Force-Attacken etwa zielen auf RDP-Protokolle, sowie VPN- und SSH-Zugänge, also auf exponierte IT-Assets, mit deren Monitoring gerade die IT-Verantwortlichen in kleineren Organisationen schnell überfordert sind. Untergliederte Netzwerke sind entscheidend, um laterale Bewegungen der Angreifer einzugrenzen und Zugriffe auf Daten zu beschränken. Diesen Ansatz verfolgen die Verantwortlichen aber oft nicht hinreichend, weil Legacy-Umgebungen zu komplex sind, das Segmentieren notwendige Dienste möglicherweise unterbricht oder die Ressourcen und die Expertise fehlen.

Wie wichtig ist es, auf den betroffenen Servern EDR/XDR-Lösungen einzusetzen – und worauf sollte man achten, wenn man diese Tools auswählt?

EDR oder XDR sind absolut notwendig, um Aktivitäten im Nachgang eines Exploits zu entdecken oder ihnen zuvorzukommen. Wer solche Tools aber auswählt, sollte sicherstellen, dass er über genug Kapazitäten für alle notwendigen Abwehroperationen verfügt. Ist dies nicht der Fall, empfiehlt sich die Zuhilfenahme verwalteter Sicherheitsdienste durch einen vertrauten Provider. EDR und XDR sind dafür ausgelegt, die Verweildauer der Malware und damit die Zeit für die Hacker zu verkürzen. Aber um Alerts aktiv zu beurteilen und zu priorisieren, sind kompetente Security-Operations-Experten nötig. Notwendig ist zudem die beste Kombination aus wirksamer Erkennung und niedrigem Alarmaufkommen.

Wie kann eine Zero-Trust-Architektur Admins konkret helfen, solche Exploits früher zu erkennen oder abzufangen? Haben Sie praktische Tipps für die Umsetzung?

Zero Trust erschwert die lateralen Bewegungen nach der Kompromittierung durch die Prinzipien der geringstmöglichen Privilegien sowie durch das kontinuierliche Überprüfen dieser Berechtigungen. Gleichzeitig bedeuten diese Prinzipien aber auch, dass selbst vertrauenswürdigen Applikationen nicht völlig vertraut werden kann. Denn was einmal erlaubt wurde, wird in der Folge nicht überprüft. Fortschrittliche Technologien zum Erkennen von Verhaltensanomalien haben aber verdächtiges Verhalten in SharePoint korrekt identifiziert und geblockt – und das ohne Updates von Signaturen oder Erkennungen.

Was können kleinere IT-Teams tun, die nicht die Ressourcen haben, rund um die Uhr Bedrohungen zu analysieren – ist der Einsatz von MDR-Diensten in solchen Fällen sinnvoll?

Um Angriffe effektiv zu erkennen und zu beantworten, benötigen kleinere Teams eine Kombination aus geeigneten Werkzeugen, kompetenten Experten und robusten Abläufen. Diese Unternehmen profitieren in sehr hohem Maße von einer Managed Detection and Response, welche die ressourcenintensive Rund-um-die-Uhr-Überwachung übernimmt. Kontinuierlich überwachen solche Angebote die Gefahren. Experten liefern Analysen und die Fähigkeit zur schnellen Reaktion auf Gefahren. Effizient verbessern Unternehmen ihren IT-Sicherheitsstatus, ohne nennenswert intern investieren zu müssen. MDR bietet ein erschwingliches und hocheffizientes Angebot für Unternehmen aller Größen – gerade auch angesichts solcher Gefahren wie der aktuellen ToolShell-SharePoint-Schwachstelle.

Wie kann man sich als Admin besser auf die nächste kritische Schwachstelle vorbereiten – gibt es konkrete Routinen, Checklisten oder Tools, die Sie empfehlen?

Ein erster Schritt dafür ist es, proaktives Patching zu implementieren. XDR und EDR bieten zudem ein robustes Set an Technologien. Administratoren sollten Netzwerke segmentieren und einen detaillierten Abwehrplan festgelegt haben. Ebenso wichtig ist es, kontinuierlich die Feeds einer Threat Intelligence zu überwachen.

Vielen Dank für das Gespräch!