
Hut ab vor der großartigen Arbeit, die die Community und die Industrie in Bezug auf den „ToolShell“-Angriff auf Microsofts On-Premise SharePoint-Server geleistet haben. Ziel dieses Artikels ist es, auf dieser großartigen Arbeit aufzubauen und Sumo Logic-Kunden mit On-Prem-SharePoint-Servern zu helfen, Beweise in ihren Umgebungen zu untersuchen und zu identifizieren.
Eine kurze Zusammenfassung der Ereignisse
Am 18. Juli 2025 identifizierte Eye Security einen Angriff auf lokale SharePoint-Server, bei dem eine verdächtige .aspx-Datei geschrieben und digitale Machine Keys extrahiert wurden. Die Analyse der Angriffskette deckte ein Schwachstellenpaar auf, das im Zusammenhang mit einem früheren Schwachstellenpaar und den von Microsoft dafür veröffentlichten Patches steht.
Die Angreifer wurden dabei beobachtet, wie sie zwei Schwachstellen, eine kritische Schwachstelle für die Ausführung von Remotecode (CVE-2025-53770) und eine Server-Spoofing-Schwachstelle (CVE-2025-53771) gegen On-Prem-SharePoint Server (2013, 2016, 2019 und Subscription Edition) ausnutzten, um eine Webshell mit dem Ziel einzusetzen, Zugriff auf die digitalen Machine Keys des Servers zu erhalten.
Am 19. Juli 2025 veröffentlichte Microsoft einen Notfall-Out-of-Band-Patch für SharePoint-Server sowie eine Anleitung für Kunden mit einem MSRC-Blogbeitrag über das Patchen der SharePoint-Server, das Rotieren der ASP.NET-Machine Keys der SharePoint-Server und zusätzliche Empfehlungen zur Erkennung und Suche.
Beginnen wir mit der Jagd und Erkennung in Sumo Logic:
Wenn wir den Angriff in seine Bestandteile zerlegen, können wir die Suche und die Erkennung durch Cloud-SIEM verbessern.
Lassen Sie uns ein Beispiel für die Suche nach den Rohprotokollen in der Umgebung eines Kunden mit der Sumo Logic-Plattform und den normalisierten Datensätzen aus dem Sumo Logic Cloud-SIEM verwenden.
Zum Start der Exploit-Kette beginnt der Initialzugriff mit einem POST-Vorgang an die ToolPane.aspx, der sich in den Logs durch ein charakteristisches URI-Muster identifizieren lässt. Diese Stub-Queries ermöglichen es, nach Versuchen zu suchen, auf diese Weise mit SharePoint zu interagieren.
_sourceCategory=prod/web/iis "ToolPane"
| parse "* * * * * * * * * * * * * * *" as date time cs-method cs-uri-stem cs-uri-query s-port cs-username c-ip cs(User-Agent) sc-status sc-substatus sc-win32-status time-taken
| where cs-method matches "POST"
AND cs-uri-stem matches "*/_layouts/*/ToolPane.aspx*"
Cloud-SIEM-Datensatzsuche:
_index=sec_record_network "ToolPane"
| where http_method matches "POST"
AND %"fields.cs-uri-stem" matches "*/_layouts/*/ToolPane.aspx*"
AND http_referer_path matches "/_layouts/SignOut.aspx"
Der http_referrer_path = /_layouts/SignOut.aspx ist ein weiterer wichtiger Aspekt der Exploit-Kette, da der gefälschte Referrer eine Umgehung der Authentifizierungskontrollen ermöglicht.
Hier ist eine Suche nach dem zentralen bösartigen Element dieser Angriffskette – der Webshell, die die Angreifer genutzt haben, um Machine Keys und weitere Ziele vom kompromittierten SharePoint-Server zu extrahieren.
Sumo Logic-Suche:
_sourceCategory=prod/web/iis
| parse "* * * * * * * * * * * * * * *" as date time cs-method cs-uri-stem cs-uri-query s-port cs-username c-ip cs(User-Agent) sc-status sc-substatus sc-win32-status time-taken
| where cs-uri-stem matches /spinstall\S?\.aspx/
AND cs-method = "GET"
Cloud-SIEM-Datensatzsuche:
_index=sec_record_network "aspx"
| where http_method = "GET"
AND %"fields.cs-uri-stem" matches /spinstall\S?\.aspx/
Die obige Webshell ermöglicht es Angreifern, Ziele auf dem Zielserver auszuführen. Diese Aktivität wird von Analysten als wichtige und erkennbare Verhaltensabweichung für SharePoint-Server bezeichnet.
Zunächst suchen wir nach w3wp.exe als Parent-Prozess für einen cmd.exe-Prozess. Die Ergebnisse dieser Suche werden für nachfolgende Suchen nach PowerShell-Ausführungen und im Zusammenhang mit diesen Angriffs-Webshell-.aspx-Dateien verwendet.
Sumo Logic-Suche:
_sourceCategory=windows_event_logs
| json field=_raw "EventData.CommandLine" as commandLine
| json field=_raw "Computer"
| json field=_raw "EventData.ParentImage" as parentImage
| json field=_raw "EventData.Image" as image
| where toLowerCase(Image) matches "*cmd.exe"
AND toLowerCase(parentImage) matches "*w3wp.exe"
| count by Computer,parentImage,image,commandLine
Cloud-SIEM-Datensatzsuche:
_index=sec_record_endpoint
| where toLowerCase(parentBaseImage) matches "*w3wp.exe"
AND toLowerCase(baseImage) matches "*cmd.exe"
| count by device_hostname,parentBaseImage,baseImage,commandLine
Cloud-SIEM-Tipp: Verwenden Sie die obigen Abfragen, um Hosts zu finden, die eine genauere Betrachtung (und einen höheren Schweregrad im SIEM-Alerting) verdienen.
Mit Match Lists, einer hilfreichen Funktion für-Cloud SIEM-Kunden, können Sie den normalisierten Datensätzen Metadaten hinzufügen. Dies ist auch hilfreich, um den Überblick über sensible Geräte zu behalten, damit Sie schnell nach Datensätzen suchen können. Zusätzlich gibt es die Funktionalität der Entitätskennzeichnung und der Entitätskritikalität. Die Kritikalität erhöht den Schweregrad der Signale für diese bestimmte Entität.
Alle diese Funktionen zusammen ermöglichen: die schnelle Identifizierung von SharePoint-Servern in Ihrer Umgebung bei der Suche nach Datensätzen (Match-Listen) und die Kennzeichnung der SharePoint-Server zur Erhöhung der Entity-Kritikalität, um sicherzustellen, dass Signale und Insights innerhalb des Sumo Logic Cloud-SIEM erstellt werden.
Zweitens: PowerShell-Ausführung unter Verwendung der oben genannten Hosts.
Sumo Logic-Suche:
_sourceCategory=windows_event_logs
| json field=_raw "Computer"
| json field=_raw "EventData.ParentImage" as parentImage
| json field=_raw "EventData.Image" as image
| where Computer IN ("[Liste der Hosts oben einfügen]","...")
AND toLowerCase(image) matches "*powershell.exe"
Cloud-SIEM-Datensatzsuche:
_index=sec_record_endpoint
| where device_hostname IN ("[Liste der Hosts oben einfügen]","...")
AND toLowerCase(baseImage) matches "*powershell.exe"
Ein Vorbehalt bei dieser Suche: PowerShell kann auf mehrere Arten über die Befehlszeile aufgerufen werden. Dies ist eine Möglichkeit und die Art, die im Referenzmaterial zu diesem Angriff beschrieben wird. Es wird empfohlen, diese und andere Rechner, die sich möglicherweise im Wirkungsradius dieses Angriffs befinden, gründlich zu untersuchen, sofern es die Zeit und der Vorfall erlauben.
Der dritte Schritt im Prozess: das Schreiben der Webshell in das Dateisystem auf Hosts im Netzwerk.
Sumo Logic-Suche:
"aspx"
| json field=_raw "EventData.TargetFilename" as targetFilename nodrop
| json field=_raw "EventData.CommandLine" as commandLine nodrop
| json field=_raw "Computer" nodrop
| json field=_raw "EventData.ParentImage" as parentImage nodrop
| json field=_raw "EventData.Image" as image nodrop
| where toLowerCase(targetFilename) contains "aspx"
Cloud-SIEM-Datensatzsuche:
_index=sec_record_endpoint aspx
| where baseImage matches "*powershell.exe"
AND changeTarget contains "aspx"
[Bonus-Inhalt] Eine Abwandlung der obigen Suche, um nach möglichen anderen Quellen von .aspx-Dateien zu suchen, die in Endpunkt-Datensätzen geschrieben werden.
Cloud-SIEM-Datensatzsuche:
_index=sec_record_endpoint aspx
| where changeTarget contains "aspx"
Dies identifiziert die Erstellung von .aspx-Dateien innerhalb normalisierter Endpunktdatensätze; es ist jedoch nicht darauf beschränkt, dass PowerShell diese Dateien schreibt. Denken Sie daran, dass es sich hierbei um eine Hunting-Analyse handelt, die eher für eine sehr spezifische Erkundung als für eine kontinuierliche Nutzung gedacht ist.
Hinweis: Die Eingrenzung der Abfrage durch Verwendung von _sourceCategory= (Rohprotokolle) und sec_record-Indizes wird für eine eingegrenzte und leistungsfähige Suche dringend empfohlen. Wenn Sie jedoch nach verdächtigen Aktivitäten in mehreren Quellenkategorien suchen, ist es sinnvoll, zunächst breit anzufangen, um Aktivitäten schnell zu identifizieren und die Suche nach Bedarf einzugrenzen.
Diese Abfragen erheben keinen Anspruch auf Vollständigkeit bei der Erkundung der betroffenen SharePoint-Infrastruktur, sondern dienen dazu, die Untersuchung potenziell betroffener Umgebungen zu beschleunigen.
Sumo Logic Cloud-SIEM-Erkennungen
Sumo Logic Cloud-SIEM-Kunden haben die folgenden Regeln in ihren Umgebungen laufen, die ihnen helfen, Signale und Erkenntnisse von betroffenen Systemen (und anderen damit verbundenen Entitäten) zu identifizieren und darauf zu reagieren.
Bei den Cloud-SIEM-Regeln konzentrieren sich die folgenden auf verdächtige Ausführungen auf dem SharePoint-Zielserver. Sie suchen nach einer Reihe von Aktivitäten (einige allgemeiner als die anderen), die sich hauptsächlich um SharePoint drehen.
Wie bereits erwähnt, verfügt Cloud-SIEM über Entity Tagging und Match Lists, wertvolle Tools zur Identifizierung und Erhöhung des Schweregrads auf SharePoint-Servern.
| Cloud-SIEM-Regel-ID | Name der Regel |
| MATCH-S00164 | Verdächtige Shells, die von Webservern erzeugt werden |
| SPIEL-S00539 | Webserver, die verdächtige Prozesse ausführen* |
| FIRST-S00010 | Erste gesehene PowerShell-Ausführung vom Computer |
| MATCH-S00136 | PowerShell-kodierter Befehl |
* MATCH-S00539 erfordert die Erstellung und Befüllung der “web_servers”-Übereinstimmungsliste, um die Ausführung von Prozessen auf Ihren Webservern zu erkennen. Hier sehen Sie, wie Sie eine Trefferliste erstellen.
Threat Intelligence ist der Schlüssel zum Aufspüren neuer und aufkommender Bedrohungen, da im Zusammenhang mit diesem Angriff Anhaltspunkte für eine Gefährdung bekannt geworden sind. Wir empfehlen Ihnen, Threat-Intelligence-Treffer im Zusammenhang mit Ihrer SharePoint-Infrastruktur auf mögliche Ermittlungsmöglichkeiten hin zu überprüfen. Zum Zeitpunkt der Erstellung dieses Artikels wurden die Indikatoren in Blog-Beiträgen veröffentlicht und sind nicht unbedingt in den größeren Threat Feeds aufgetaucht.
| Cloud-SIEM-Regel-ID | Name der Regel |
| MATCH-S01023 | Threat Intel – Inbound Traffic from Threat Feed IP (High Confidence) |
| MATCH-S01027 | Threat Intel – Inbound Traffic from Threat Feed IP (Medium Confidence) |
| MATCH-S01025 | Threat Intel – Inbound Traffic from Threat Feed IP (Low Confidence) |
| MATCH-S01000 | Threat Intel – MD5 Match |
| MATCH-S01003 | Threat Intel – SHA1 Match |
| MATCH-S01004 | Threat Intel – SHA256 Match |
Mit Sumo Logic Threat Intelligence können Kunden ihre eigenen Indikatoren hochladen und auch aus benutzerdefinierten Quellen einlesen. Angesichts der wenigen Indikatoren, die von der Community gemeinsam genutzt werden, ist die Erstellung einer Threat Intelligence-Quelle für Cloud-SIEM-Regeln eine Option für eine schnelle Abdeckung und Einbindung in die oben genannten Regeln. Kunden können auch lokale Threat-Intelligence-Regeln erstellen und dabei die von ihnen erstellte benutzerdefinierte Quelle nutzen (d.h. hasThreatMatch([srcDevice_ip,file_hash_md5,file_hash_sha256], source=”toolshell iocs”).
Vorgeschlagene Erkennungstheorien für die Entwicklung lokaler Regeln
Hier finden Sie einige Beispiele für Erkennungstheorien, die in Cloud-SIEM-Match-Expressions umgewandelt wurden, damit Sie in Ihren Umgebungen Regeln erstellen können, um Elemente dieses Angriffs zu erkennen.
Cloud SIEM – die erste Zugriffs-POST-Anfrage für die Exploit-Kette:
http_method = 'POST'
AND http_response_statusCode IN (200, 302)
AND http_referer_path MATCHES /(?i)_layouts\/1[56]\/signout\.aspx$/
AND fields['cs_uri_stem'] MATCHES /(?i)_layouts\/1[56]\/toolpane\.aspx$/
Theorie: Erkennung des POST, der den ersten Zugriff des Angriffs auslöst und dazu führt, dass die Webshell auf dem anfälligen System installiert wird.
Die ausführbare Datei von Cloud-SIEM wurde dem IIS-Verzeichnis hinzugefügt:
action = "FileCreate"
AND changeTarget MATCHES /(?i:\\wwwroot\\|\\windows\\microsoft\.net\\\framework\\|\microsoft shared\\\web server extensions\\).+\.(?i:as[hmp]x|cshtml)$/
AND baseImage NOT MATCHES /(?i)(?:\\w3wp|\\msdeploy|\\svchost|\\explorer)\.exe$/
Theorie: Erkennen der Aktion eines FileCreate für eine ausführbare Datei (in diesem Zusammenhang Webshell), die in das IIS-Verzeichnis geschrieben wird.
Cloud-SIEM erkennt Interaktion mit der Webshell über GET:
http_method = 'GET'
AND http_response_statusCode IN (200,302)
AND fields['cs_uri_stem'] MATCHES /(?i)_layouts\/1[56]\/spinstall\d{0,2}\.aspx/
Theorie: Nachdem der Angreifer das System mit der durch das obige POST gestarteten Exploit-Kette kompromittiert hat, erfasst diese Erkennung die Interaktion mit der Webshell, während sie Ziele auf dem Zielsystem ausführt.
Diese Erkennungstheorien werden als Prototypen freigegeben, um die Erstellung lokaler Erkennungsregeln zu beschleunigen und die Erkennung und Untersuchung mutmaßlich gefährdeter Umgebungen zu unterstützen. Sie wurden speziell für die Ausführung als Match Expressions für Sumo Logic Cloud-SIEM entwickelt und können so angepasst werden, dass sie ähnliche Ergebnisse wie die oben genannten gemeinsamen Suchen liefern.
Empfehlungen
Microsoft bietet detaillierte Anleitungen zum Schutz vor potenziellen Ausnutzungen dieser Schwachstelle in Ihrer Umgebung sowie Abhilfemaßnahmen, wenn Sie feststellen, dass Ihre Sharepoint-Server gefährdet sind.
Die Ausnutzung der SharePoint-Schwachstellen ist trivial. Wenn Sie anfällige SharePoint-Server in Ihrer Umgebung haben, müssen Sie feststellen, ob sie kompromittiert wurden, und wenn ja, wie groß der Schaden ist und welche Abhilfemaßnahmen erforderlich sind. Sobald Angreifer Ihre SharePoint-Server erfolgreich kompromittiert haben, können sie von SharePoint auf andere Ressourcen in Ihrer Umgebung übergehen. Die in diesem Artikel enthaltenen Abfragen können Ihnen helfen, festzustellen, ob eine Kompromittierung stattgefunden hat.
Jetzt haben Sie eine kurze Analyse und eine Zeitleiste des laufenden Angriffs auf On-Prem-SharePoint-Server und wissen, wie Sie Sumo Logic verwenden, um nach verdächtigen Aktivitäten zu suchen und diese zu erkennen. Wenn Sie tiefer in das Thema einsteigen möchten, stehen Ihnen unten weitere Quellen zur Verfügung.
Und wie immer gilt: Wenn Sie noch kein Cloud-SIEM haben und verstehen möchten, wie es Ihnen helfen kann, Bedrohungen wie diese zu erkennen und darauf zu reagieren, buchen Sie eine Demo, um mehr zu erfahren.
Referenzen und weitere Ressourcen
Informationen zur NIST-Schwachstelle:
Microsoft MSRC-Blog für betroffene SharePoint-Kunden:
Der Blog-Beitrag von Eye Security, in dem erstmals über den Angriff berichtet wurde:
Ressourcen der Cybersicherheitsgemeinschaft und Berichte, die den Angriff dokumentieren:
- https://www.crowdstrike.com/en-us/blog/crowdstrike-detects-blocks-sharepoint-zero-day-exploitation/
- https://www.thawd.com.sa/post/cve-2025-53770-unauthenticated-sharepoint-rce-toolshell-exploit-uncovered
- https://blog.qualys.com/vulnerabilities-threat-research/2025/07/21/toolshell-zero-day-microsoft-rushes-emergency-patch-for-actively-exploited-sharepoint-vulnerabilities
- https://www.microsoft.com/en-us/security/blog/2025/07/22/disrupting-active-exploitation-of-on-premises-sharepoint-vulnerabilities/
- https://unit42.paloaltonetworks.com/microsoft-sharepoint-cve-2025-49704-cve-2025-49706-cve-2025-53770/
- https://www.rapid7.com/blog/post/etr-zero-day-exploitation-of-microsoft-sharepoint-servers-cve-2025-53770/

