Kurzer Hinweis in eigener Sache. Über den Cybervorfall bei der Südwestfalen-IT, bei dem die Ransomware-Gruppe Akira das Rechenzentrum des Kommunaldienstleisters lahm legte, hatte ich ja berichtet. In diesem Kontext habe ich auch eine Zusammenfassung der Erkenntnisse aus der forensischen Analyse bei Golem veröffentlicht.
Anzeige
Details zum Cybervorfall sowie meine Aufarbeitung hier im Blog lassen sich ja über die nachfolgend verlinkten Beiträge nachlesen. Für Golem habe ich eine Zusammenfassung der Erkenntnisse aus dem Forensik-Bericht im Beitrag Vertraulicher Forensik-Bericht offenbart viele Versäumnisse veröffentlicht.
Ergänzung: An dieser Stelle noch zwei Nachträge für die Leserschaft. Im Forum Wermelskirchen gab es eine Kopie des Forensik-Berichts. Ich selbst hatte mich – u.a. nach Diskussion mit einem Leser – dagegen entschieden, diesen Forenpost zu verlinken oder den Bericht hier bei mir im Blog einzustellen. Ich hatte zwar keine Auflagen von der Pressebetreuung, die mir den Bericht zur Verfügung gestellt hat, erhalten. Aber vor dem Hintergrund, dass der Bericht als vertraulich gekennzeichnet war, habe ich mich gegen eine Veröffentlichung entschieden.
In einem heutigen Telefonat mit der zuständigen Pressebetreuung gab es den Konsens, das auch weiterhin so zu belassen. Inzwischen ist die Kopie des Forensik-Berichts aus dem Forum entfernt worden. Ein Leser hat mich auf diesen Sachverhalt sowie auf seine Zusammenfassung hier hingewiesen (danke dafür).
Artikelreihe:
Ransomware bei Kommunal IT-Dienstleister Südwestfalen-IT: Nachlese IT-Forensik-Bericht Teil 1
Ransomware bei Kommunal IT-Dienstleister Südwestfalen-IT: Nachlese IT-Forensik-Bericht Teil 2
Ähnliche Artikel:
Stillstand nach Cyberangriffen auf Kommunen in Südwestfalen und Parkhäuser in Osnabrück
Cyberangriff auf Südwestfalen IT trifft mindestens 103 Kommunen
Neues zum Cyberangriff auf Südwestfalen IT
Cyberangriff auf Südwestfalen IT (SIT): Chaos bei betroffenen Kommunen
Südwestfalen IT (SIT) will bald erste Fachverfahren nach Angriff wieder freischalten
Südwestfalen IT: Wiederanlauf nach Cyberangriff dauert länger; Betreiber werden Versäumnisse vorgeworfen
Ransomware bei Kommunal IT-Dienstleister Südwestfalen-IT; Stand Januar 2024
Anzeige
Anzeige
Ich habe mir mal den verlinkten Blogbeitrag durchgelesen und für mich stellt sich gerade die Frage: wo zum Henker kann man Credentials in einer GPO ablegen? Ich kann weder Accounts anlegen via GPO, noch ein WLAN PW mitgeben.
Via Powershell schon, ich weis. Der einzige Fall wo das Sinn macht: LAPS Impelementierung, aber da kann man bei der Erstellung des Account ein Random-PW vergeben da es eh überschrieben wird und nein, man nutzt dafür nicht den "Administrator" – der Account gehört deaktiviert.
Wer zur Hölle hinterlegt irgendwo Kennwörter,in Klartext (da komme ich gerade nicht klar drauf :[ ) ? Das ist schon nicht mehr fahrlässig, dass ist Absicht, aber dafür wird am Ende eh keiner belangt und die "Manager" werden wegbefördert … :(
Das man Credentials in einer GPO ablegen kann ging früher.
Die Lücke wurde mit dem Sicherheitsupdate vom März 2015 geschlossen!
Den Patch gabs damals für Server 2003/2008/2008R2/2012/2012R2 und Windows Vista/7/8/8.1.
Server 2016 und Windows 10 gabs damals noch nicht.
ich hab es mir gedacht :D, aber dann waren die mit dem Domänen-Funktionslevel irgendwo auf 2003 oder 2008 – traurig :| – also in deren Management-Netz bzw. eigenem AD.
Stellt sich mir jetzt aber auch die Frage: sind alle "Kunden" im gleichen AD Domain-Forrest unterwegs oder hatten die Übergeordnet Ihre eigene Domain stehen? Es macht eigentlich keinen Sinn, dass alle "Kunden" Mitglied der gleichen Domain sind – wenn das deren "Sicherheitskonzept" war, dann aber gute Nacht .. aber ist halt "billiger" man braucht nur noch einen Exchange und kann den dann x-Mal abrechnen …
das Domänen Level hat nix mit den GPOs zu tun. Die GPO wurde 2014 angelegt und darin lag das PW, mit dem Patch wurde nur die Möglichkeit entfernt PW in der GPO zu hinterlegen.
Bereits bestandene GPOs werden durch patches nicht verändert und hätten spätestens damals nach dem Patch kontrolliert werden müssen ob irgendwo ein PW abgelegt war. Das Sicherheitsproblem der auslesbaren PW war eigentlich schon lange davor bekannt, aber es hat kaum jemanden interessiert, es wurde trotzdem genutzt, weshalb dann MS einen Riegel davor geschoben hat.
Der Fehler war nicht nur, dass ein Admin PW dort hinterlegt war, sondern dass das PW auch seit 2014 scheinbar nie wieder geändert wurde.
Never Touch a Running System 😉
Geht heute nicht mehr, wird seid 2014 von Microsoft verhindert:
https://support.microsoft.com/en-gb/topic/ms14-025-vulnerability-in-group-policy-preferences-could-allow-elevation-of-privilege-may-13-2014-60734e15-af79-26ca-ea53-8cd617073c30
Nun rate mal, wie der Abschlussbericht zu genau diesem Datum kommt…
Einschlägig bekannte Tools (z.B. PowerSploit) können diese Auslesen:
https://www.powershellgallery.com/packages/PowerSploit/3.0.0.0/Content/Exfiltration%5CGet-GPPPassword.ps1
das zeigt nochmals wie extrem wichtig das Offenlegen des Einbruchsweges ist.
Ich fürchte, das noch viele Systeme existieren, die auch noch das Domain Passwort in der GPO gespeichert haben…
Wer rechnet denn mit so etwas, das der Patch nicht auch die Passwörter entfernt?
In der Linux Welt gibt es Scripte die auf solche Fehler prüfen, dunkel erinnere ich mich, das es so etwas mal auch für Windows gab, aber dann wohl eingestellt wurde?
Aber das würde auch bedeuten dass das Passwort seit Schliessen der Lücke nicht mehr geändert wurde, oder?
Da kommt man aus dem Staunen nicht mehr raus…
Entweder das, oder das das System seit der Zeit ungepatcht ist.
So nach dem Motto: "Sicherheitspatches sind nur etwas für Angsthasen…."
natürlich dürfen Patches keine GPOs anrühren. Wie genau soll das auch funktioniert, dass es dann alle Daten scannt und die einzelnen Einträge aus einer Datei entfernt auf Daten die eigentlich ein Administrator dort abgelegt hat….keine gute Idee.
Ohne mir den Bericht durchgelesen zu haben – es heißt, das Passwort war nicht im Klartext, sondern gehasht dort abgelegt. Nur ist der Hash als Nebenfolge irgendweiner einer EU-Anforderung leicht auflösbar.
aaO:
770 Server und 4.176 Clients der Domäne intra.lan
hilft Dir das bei der Frage nach dem Forrest?
ja, ein Grund mehr die Geschäftsleitung dafür in den Knast zu stecken und das nicht nur für grobe Fahrlässigkeit sondern bewusstes herbeiführen eines solches Schadenszenarios.
Ebenso gehören die GF der SIT mit auf die Anklagebank ..
Wir werden aber sehen, es hat für irgendwelche Entscheider keinerlei Auswirkung und aus dem Grund wird sich auch nichts ändern. War ja höhere Gewalt und ein ausgeklügelter und hinterhältig geplanter H4ck0r Angriff :-)
Das ist aber auch typisch Deutschland…. es werden Berater hinzugezogen, die sagen " ja kann vielleicht". Anstatt das System neu aufzubauen und die Datenbackups einzuspielen wird erst viel philosophiert.
Eigentlich hätte man das als Chance nutzen können, mal die ganze Architektur (insbesondere SEGMENTIERUNG) zu überdenken und das System neu aufzubauen.
Da sollte man sich auch Input von diversen Externen holen und sich seine eigene Meinung bilden.
Wenn ich allein schon die ganze Latte an "Partnern" dieser Beratung sehe.. make it easy, nicht "NEXT GEN".
Ich kann dir versichern, das Netzwerk wurde nicht so durchlässig aufgebaut wie es war. Jedenfalls soweit ich das als Netzwerk-Amateur beurteilen kann.
ja, doch, klar.. intra.lan als Zugangspunkt für 770! Server und 4176 Clients. Der Abschlussbericht ist einfach nur gruselig und die Maßnahmenempfehlungen ebenso.
Das wird zu kompliziert.. es wurde ja schon über Fluktuation gesprochen und wenn noch diverse "Partner" ins Boot geholt werden: viel Erfolg!
Das sind 4000 Clients und fast 1000 Server.
Das stellt man nicht so schnell mal um.
Allerdings wundert es mich, wofür die 1000 Server gebraucht haben, wenn es nur 4000 Clients gab.
Das die Performance von MS Servern nicht so dolle ist ist ja bekannt, aber das man pro Server im Schnitt nur 4 Clients fahren kann doch nicht sein?
ne, dass verhältnis sehe ich nicht als Ungewöhnlich an.
Alleine ein kleiner SQL AlwaysOn Cluster benötigt mindestens 3 Server (2 Nodes + Wittness) und wenn man viele Dienste über MS Cluster als HA bereitstellt kommt man sehr schnell an solche Werte. Auch sollte man Fileserver immer per DFS bereitstellen und im Idealfall jeden "Hauptordner" als eigenen Server bereitstellen, aber darüber kann man jetzt viel diskutieren :)
Viel schafft viel.. eigentlich müsste es ja eine Dokumentation des Netzwerks geben und daraus hätte man etwas Neues bauen können
120 Angestellte? plus ein paar Externe.. die hätten schon einiges in drei Monaten betanken können.
Zwischen den 4.000 stecken vermutlich auch Terminalserver.