Südwestfalen-IT

Inhaltsverzeichnis
  1. Quellen
  2. Lernen
  3. Lernen
  4. Weitere Links

Der Ransomware-Angriff auf die Südwestfalen-IT ist einer breiteren Öffentlichkeit durch diverse Meldungen in Funk, Fernsehen und anderen Medien bekannte geworden. Gerade auch die Zeitungen in OWL haben darüber berichtet, dass Angestellte von betroffenen Gemeinden z.B. täglich mit Akten zur KFZ-Zulassungsstelle gependelt sind, um dort einen Notbetrieb aufrecht erhalten zu können.

Quellen

Wie zuverlässig all diese Pressemeldungen sind, muss nun jeder selbst entscheiden. Meist sind es Vermutungen, denn solange der Thread noch aktiv ist, haben die verantwortlichen Personen sicher andere Prioritäten als mit Presse zu sprechen und es braucht auch Zeit sich selbst erst einmal ein Bild zu machen. Allerding wird es immer gerne gesehen, wenn eine Firma mit etwas Abstand eine "Root Cause Analyse" bereitstellt. Microsoft macht dies relativ detailliert, wenn man zwischen den Zeilen lesen kann.

Um so wichtiger ist, es, dass gerade deutsche Firmen ähnlich agieren und nicht aus falsch verstandener Scham das Thema totschweigen und drauf hoffen, dass es vergessen wird. Das passiert nämlich aber hilft letztlich nur den Angreifern weitere Opfer zu finden. Ich frage mich grade, warum die Security Firmen, die solche Auswertungen am Ende machen, nicht ihre Kunden davon überzeugen zumindest eine Kurzfassung zu veröffentlichen.

Ich finde nämlich ganz wenig "Case Studies" bei genau diesen Security Firmen. Insofern ist es eher ein Zufall, dass der "Abschlussbericht Security Incident" der r-tec ende Januar 2024 zufällig auf https://forumwk.de für kurze Zeit einsehbar war. Dort gibt es einen kurzen Artikel

In dem Artikel ist aber auch der 42-seitige Incident Report (vermutlich irrtümlich) veröffentlicht ist.

https://forumwk.de/wp-content/uploads/2024/01/SIT_Incident_Response_Bericht_210777_v1.1_blackened_conf.pdf

An Anfang war die URL noch "https://forumwk.de/wp-content/uploads/2024/01/SIT_Incident_Response_Bericht_210777_v0.15_blackened_signed_confidential.pdf", die aber kurz darauf nicht mehr erreichbar war. Aber dafür gab es dann die Wayback-Machine:

Über die "Wayback-Machine" aber noch erreichbar. Soviel zu "Internet vergisst nichts"
https://web.archive.org/web/20240127035024/https://forumwk.de/wp-content/uploads/2024/01/SIT_Incident_Response_Bericht_210777_v0.15_blackened_signed_confidential.pdf

Auf ca. 42 Seiten erläutert r-tec ihre Analysen, Schlussfolgerungen und vermutliche Angriffswege und Vektoren. Servernamen, IP-Adressen und Personen sind geschwärzt.

Bislang hat Südwestfalen-IT nur eine sehr kurze "pressetaugliche" Fassung veröffentlicht:

Allerdings würde ich diese Seite als etwas geschönt bezeichnen. Dennoch können Sie aus den Fehlern lernen.

Lernen

Vermutlich sind folgende Faktoren zusammengekommen, die es dem Angreifer erleichtert haben:

Fehler Draus lernen

Sorry, aber das war keine Zeroday-Lücke

Es gibt sicher Lücken in Systemen, die von Angreifern ausgenutzt werden aber eine 0-day/Zero-Day-Lücke zeichnet sich dadurch aus, dass zum Zeitpunkt des Angriffs diese Lücke dem Hersteller nicht bekannt war und er damit keine Updates und Warnungen verbreiten und die Kunden diese Updates installieren konnten. Wenn erste Zugriffe am 18. Okt und der Angriff am 30. Okt erfolgt aber die Lücke schon im September vom Hersteller korrigiert wurde, dann kann man sich nicht auf einen 0-Day berufen.

VPN-Server (CiscoASA) ohne MFA, d.h. BruteForce-Angriffe auf Username/Kennwort möglich und vermutlich der Weg zum internen Netzwerk.

Ist ihre VPN-Lösung sicher, z.B. per MFA oder mit Zertifikaten abgesichert? Oder nutzen sie immer noch allein Benutzername/Kennwort, die nach vielen Fehlversuchen nicht gesperrt werden?

Einmal im Netz konnte sich der Angreifer sich vermutlich als Domain User umschauen und hat vermutlich weitere Schwachstellen gefunden.

Sind ihre Server alle noch ein einem Subnetz oder haben Sie schon mit Firewalls segmentiert und Verbindungen auf notwendige Zugriffe beschränkt? Es gibt jede Menge Tools, um Scannen ihres Netzwerks, z.B.:

Es ist so einfach zumindest die offensichtlichen Fehler zu entdecken und zu beseitigen.

Zugangsdaten des Domain Admin in einer Gruppenrichtlinie (in einem Skript?) hinterlegt und lesbar?

Das dürfte eine sehr alte Altlast gewesen sein aber passiert in den besten Kreisen. Sind sie wirklich sicher, dass nicht in irgendwelchen Skripten ein "RunAs", oder "NET USE  /User Password" o.ä. hinterlegt ist, welches von DomainUser gelesen werden darf? Aber haben wir nicht all irgendwo "gespeicherte Kennworte? Ich habe schon SYSLOG-Freigaben mit Gruppenrichtlinien und "Startup-Skripten" gesehen, die von DomainUser beschreibbar waren.

So prüft z.B. Purple Knight genau dies:

Analyse erschwert, da die Protokolle nicht mehr vorhanden/überschrieben waren.

Netzwerk-Geräte haben meist einen sehr geringen speicher und können ihre Logs per SYSLOG verwenden. Windows Server schreiben ihre Daten ins Eventlog, die aber begrenz sind und ein Angreifer kann diese Log auch löschen um Spuren zu verwischen. Sammeln Sie ihre Eventlog in einem zentralen System, welches auch "autark" ist?

Übrigens gilt dies auch für ein Backup. Angeblich haben die Angreifer auch versucht die Kennworte aus einer Veeam-Datenbank auszulesen. Vielleicht sollte sich das Backup die Daten holen und nicht selbst in der Domain eingebunden sein.

Tier 0/1/2 - RDP-Zugriff per VPN auf Domain Controller

Die Verzeichnisserver in ihrem Netzwerk sind die Kronjuwelen. Sie sollten besonders geschützt sein. Insbesondere könnten Sie schon sicherstellen, dass der RDP-Zugang nicht von jedem Endgerät sondern nur von ausgewählten Admin-Clients möglich ist. Das hilft natürlich nicht, wenn der Angreifer per C$ oder Remote PowerShell oder RCMD auf dem DC eigene Programme starten kann, aber auch hier wäre zu prüfen, ob das ein VPN-User dürfen muss.

Ich war in keiner Weise bei dem Incident eingebunden und lese nur öffentlich zugängliche Informationen um meine eigenen Schlüsse draus zu ziehen und jeden Tag besser zu werden.

Ob da nur ein neuer Geschäftsführer hilft, muss sich erst beweisen. Ich hoffe, dass sich die Denkweise und die Prioritäten nun ändern, auch wenn es nicht günstig ist. Wer nun Schadenfreue empfindet, möge einmal in seinen eigenen Maschinenraum schauen. Ich bin sicher, dass dies bei der Südwestfalen-IT gerade passiert und bei erfolgten Neuaufbau dies konsequent umgesetzt werden sollte. Alle anderen haben es noch vor sich.

Lernen

Aber Hand aufs Herz: Können Sie für sich das alles ausschließen? Ich bin sicher, dass jede Firma Kompromisse eingehen wird. Nutzen Sie die Informationen um nicht nur ihre Mitarbeiter in der IT, sondern auch alle anderen zu sensibilisieren.

Wenn Sie ein Sicherheitsaudit ihres Active Directory, AzureAD, Exchange o.ä. brauchen, dann sprechen Sie meine Kollegen vom Net at Work SOC oder mich einfach an.

Weitere Links