Golem-Artikel: Erkenntnisse zum Cybervorfall bei Südwestfalen-IT

Sicherheit (Pexels, allgemeine Nutzung)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


Cookies blockieren entzieht uns die Finanzierung: Cookie-Einstellungen

Dieser Beitrag wurde unter Sicherheit abgelegt und mit verschlagwortet. Setze ein Lesezeichen auf den Permalink.

19 Antworten zu Golem-Artikel: Erkenntnisse zum Cybervorfall bei Südwestfalen-IT

  1. Joerg sagt:

    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 … :(

    • R.S. sagt:

      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.

      • Joerg sagt:

        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 …

        • Michael sagt:

          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.

      • Hans sagt:

        Never Touch a Running System 😉

    • unbekannt sagt:

      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

      • Pau1 sagt:

        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?

        • nk sagt:

          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…

        • Michael sagt:

          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.

    • Egon sagt:

      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.

  2. Pau1 sagt:

    aaO:
    770 Server und 4.176 Clients der Domäne intra.lan

    hilft Dir das bei der Frage nach dem Forrest?

    • Joerg sagt:

      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 :-)

  3. Ano sagt:

    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".

    • SIT Kunde sagt:

      Ich kann dir versichern, das Netzwerk wurde nicht so durchlässig aufgebaut wie es war. Jedenfalls soweit ich das als Netzwerk-Amateur beurteilen kann.

      • Ano sagt:

        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!

    • Pau1 sagt:

      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?

      • Joerg sagt:

        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 :)

  4. Ano sagt:

    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.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Hinweis: Bitte beachtet die Regeln zum Kommentieren im Blog (Erstkommentare und Verlinktes landet in der Moderation, gebe ich alle paar Stunden frei, SEO-Posts/SPAM lösche ich rigoros). Kommentare abseits des Themas bitte unter Diskussion.