True IT Stories

Der Angriff, der nicht der Einstieg war

TL;DR

  1. In den Logs einer Nextcloud fand sich ein massiver Angriff kurz vor der Ransomware. Der naheliegende Schluss wäre: Das war der Einstieg.
  2. Anfragen pro Tag zählen führt in Minuten zum Angriff, Lesen von Hunderttausenden Zeilen nicht.
  3. Dann prüfen, ob er gelungen ist: Webshell nie erreichbar, keine Datei auf der Platte, Version gepatcht. Der Verdacht war ausgeräumt.

Nach einem Ransomware-Angriff will jeder wissen: Wie sind sie reingekommen? Bei einem weiteren Server aus dem Fall, den wir in Der Decryptor läuft, und die großen VMs bleiben zu erzählen, sah die Antwort zuerst eindeutig aus. Sie war es nicht.

Wie man in Logs etwas findet

Auf dem Server lief eine Nextcloud, aus dem Internet erreichbar. Die Logs des Webservers reichten Monate zurück. Hunderttausende Zeilen liest niemand. Gezählt geht es schnell, Anfragen pro Tag:

zcat -f access.log* | awk '{print substr($4,2,11)}' | sort | uniq -c

Normal waren ein paar hundert bis einige tausend Anfragen am Tag. Über rund zehn Tage, wenige Wochen vor der Verschlüsselung, waren es das Fünf- bis Zehnfache. Für einen dieser Tage dann: Wer fragt, und wonach?

grep '<Tag>' access.log | awk '{print $1}' | sort | uniq -c | sort -n | tail
grep '<Tag>' access.log | awk '{print $7}' | sort | uniq -c | sort -n | tail

Eine Quelle, eine Adresse, über hunderttausend Anfragen. Darin ein Versuch, über den Proxy des eingebauten Collabora-Servers (App „Built-in CODE Server“) Befehle auszuführen, eine Webshell abzulegen und sich bei einem externen Dienst zurückzumelden.

Die Bruchstelle: laut heißt nicht erfolgreich

An dieser Stelle ist die Versuchung groß, den Einstieg gefunden zu haben. Ein massiver, gezielter Angriff, kurz vor der Verschlüsselung. Das passt zu gut.

Also haben wir geprüft, ob er gelungen ist:

  • Antwortcodes der Angriffsanfragen. Alle 200. Klingt nach Erfolg, heißt aber nichts: Diese Funktion antwortet immer mit 200, auch auf Unsinn.
  • Aufrufe der Webshell. Der Angreifer hat sie danach mehrfach aufgerufen. Jede Antwort 400 oder 404.
  • Die ganze Platte nach der Datei durchsucht, nicht nur das Webverzeichnis. Nichts.
  • Versionen. Nextcloud und die Collabora-App waren neuer als der Fix für die passende Lücke (CVE-2025-66208).

Ergebnis: Der Angriff ist gescheitert. Dieser Server war sehr wahrscheinlich nicht der Weg hinein. Wo der Einstieg lag, ist damit nicht geklärt, nur ein Verdacht ausgeräumt. Auch das ist Forensik.

Der Nebenbefund

Die Dokumentkonvertierung des eingebauten Collabora-Servers war ohne Anmeldung aus dem Internet nutzbar. Ausgenutzt wurde das nicht, aber es gehört beim Neuaufbau geschlossen. Collabora läuft besser als eigener Server.

Was wir prüfen würden

  • Logs aufheben, und nicht nur auf dem Server selbst. Ohne Monate zurück hätten wir nichts gesehen. Liegen sie nur lokal, sind sie im Ernstfall womöglich mit verschlüsselt.
  • Erst zählen, dann lesen. Anfragen pro Tag, pro Quelle, pro Adresse. Ausreißer zeigen, wo man lesen muss.
  • Jeden Treffer gegenprüfen. Hat die Webshell je geantwortet? Gibt es die Datei? Ein Angriff im Log ist eine Frage, keine Antwort.
  • Prüfen, was ohne Anmeldung erreichbar ist. Nicht nur, ob gepatcht ist.