Was ein Ransomware-Vorfall über die Woche davor lehrt

TL;DR: Ein öffentlicher Netzverbund wurde eine Woche exfiltriert, bevor es jemand bemerkte, und der Auslöser war eine Routinebeschwerde. Ich schreibe über die Kontrollen, die diese Verweildauer verkürzt hätten — nicht über den Angreifer.

Ausgangslage

Ich habe das Ziel als Black-Box geprüft: keine Zugangsdaten, nur die öffentlich sichtbare Fläche. Das ist, was ich sah, bevor ich etwas angefasst habe.

Eine Nach-incident-Prüfung eines öffentlichen Netzverbunds, der einen Datenabfluss- und ErpressungsVorfall erlebte. Der Umfang war eine Kontrollprüfung gegen die Incident-Timeline: initialer Zugriff, Verweildauer, Erkennungszeitpunkt, Eindämmung und Datenvolumen. Es wurde nichts an aktiven Systemen getestet.

Ich habe alle identifizierenden Informationen entfernt. Das Ziel wird ausschließlich nach Branche und Technologieklasse beschrieben, damit das Muster übertragbar bleibt.

Das Muster

Das Muster, das ich erkannt habe — und das ich in ähnlichen Landschaften immer wieder finde:

Die Zahl, die bei einem Abfluss-Vorfall zählt, ist die Verweildauer, nicht die Lösegeldforderung. Eine Woche zwischen Zugriff und Bemerken bedeutet sieben Tage ungemonitorierten Abfluss, nachgenutzte Zugangsdaten in der gesamten Landschaft und einen Datenkatalog, den niemand zusammenstellte, der hinschaute.

Der initiale Zugriff war gewöhnlich, und das ist der wichtigste Befund. Phishing mit einer gefälschten Identitätsabfrage führte zur Installation eines Fernwartungswerkzeugs auf einem Arbeitsplatz. Von dort war der Weg nicht technisch neuartig.

Der Auslöser der Erkennung war eine normale Benutzerbeschwerde, kein Sicherheitskontrollmechanismus. Die Reaktion war gut; die Erkennungsfähigkeit fehlte.

TL;DR: Ein öffentlicher Netzverbund wurde rund eine Woche exfiltriert, bevor es jemand bemerkte. Diese Analyse handelt von Kontrollen, die diese Verweildauer verkürzt hätten, nicht vom Angreifer.

Befunde

Schweregrad	Befund	Nachweis
KRITISCH	Keine Erkennung von Massen-Datentransfer nach aussen	Sieben Tage Exfiltration ohne Alarm
KRITISCH	Fernwartungssoftware auf Arbeitsplätzen nicht blockiert	Initialzugriffswerkzeug ohne Verhinderung oder Alarm installiert
KRITISCH	Gemeinsame Administrationszugangsdaten über Abteilungen	Lateral-Movement-Pfad zwischen Serversegmenten
HOCH	Keine Multi-Faktor-Authentifizierung für Administrationszugriff	Eine kompromittierte Zugangsberechtigung genügt
HOCH	Kein automatisierter Alarm bei Massen-Dateizugriffsmustern	Enumerationsphase unsichtbar
MEDIUM	Sensible personenbezogene Daten ohne definierte Aufbewahrungsregel	Exfiltrationsvolumen weit über den operativen Bedarf

Der Angriffspfad

Reproduktion im Labor

Jeder Befehl unten zielt auf einen Lab-Container, den ich selbst kontrolliere. Nichts davon ist auf ein laufendes System gerichtet.

Die Erkennungsfähigkeit im eigenen Netz verifizieren

~/code/bash bash

# gibt es überhaupt eine Egress-Warnung
$ for h in $(cat internal-hosts.txt); do
    printf '%s
' "$h"
done
# die Frage an das Netzwerkteam: löst ein Server, der über Nacht mehrere
# Gigabyte überträgt, einen Alarm aus? In einem Labor testen.

# ist Fernwartungssoftware blockierbar
$ for tool in anydesk.exe teamviewer.exe ultravnc.exe rustdesk.exe; do
    printf '%s ' "$tool"
    curl -so /dev/null -w '%{http_code}
' \
      "https://update.example.org/$tool"  # Ihre eigene Softwareverteilung
done

Erkennung in eigener Infrastruktur

Die zwei Fragen stellen, die Ihre Verweildauer entscheiden

~/code/bash bash

# 1. löst ein Server, der über Nacht mehrere Gigabyte überträgt, einen Alarm aus
#    im Labor testen, nicht in Produktion:
$ dd if=/dev/zero of=/tmp/test.bin bs=1M count=500
$ scp /tmp/test.bin labor-ziel:/tmp/test.bin   # Ihr eigener Labor-Host

# 2. ist Fernwartungssoftware blockiert und wird sie alarmiert
$ for tool in anydesk.exe teamviewer.exe ultravnc.exe rustdesk.exe; do
    printf '%s %s\n' "$tool" \
      "$(curl -so /dev/null -w '%{http_code}' "https://software.example.org/$tool")"
done

Prüfen, ob Administrationszugriff einen zweiten Faktor verlangt

~/code/bash bash

$ for p in /wp-admin/ /admin/ /api/admin; do
    printf '%s -> %s\n' "$p" "$(curl -so /dev/null -w '%{http_code}' https://example.org$p)"
done

# der echte Test ist ein Loginversuch ohne zweiten Faktor

Behebung

Den initialen Zugriff blockieren, nicht nur erkennen

~/code/nginx nginx

# Fernwartungswerkzeuge am Proxy blockieren, nicht am Arbeitsplatz
# der Arbeitsplatz ist eine Kontrolle; der Proxy ist der Engpass, den jedes Werkzeug braucht
location ~* \.(exe|msi)$ {
    if ($arg_uri ~* "(anydesk|teamviewer|ultravnc|rustdesk|splashtop)") {
        return 403;
    }
    proxy_pass http://software-distribution;
}

Keine Erkennung von Massen-Datentransfer nach aussen

Fernwartungssoftware auf Arbeitsplätzen nicht blockiert

Gemeinsame Administrationszugangsdaten über Abteilungen

Keine Multi-Faktor-Authentifizierung für Administrationszugriff

Kein automatisierter Alarm bei Massen-Dateizugriffsmustern

Sensible personenbezogene Daten ohne definierte Aufbewahrungsregel

Fazit — was ich daraus mitnehme

Die Verweildauer entscheidet, wie schlimm der Vorfall wird.
Initialer Zugriff ist selten raffiniert; er wird ebenso selten blockiert.
Eine Benutzerbeschwerde ist keine Erkennungsfähigkeit.
Gemeinsame Administrationszugangsdaten machen aus einer Kompromittierung eine flächenweite.