Zum 30. Oktober 2023 wurde die Südwestfalen IT, ein kommunaler IT-Dienstleister, Opfer eines Akira-Ransomware-Angriffs. Seit dieser Zeit ist eine zwei- bis dreistellige Zahl an Kommunen IT-mäßig offline bzw. stark eingeschränkt. Es gibt inzwischen einen Forensik-Bericht der Sicherheitsdienstleister, der mehr Informationen liefert, als öffentliche Berichte widergeben. In Teil 1 arbeite ich die Erkenntnis ab, die sich auf den ursprünglich genutzten Angriffsvektor VPN-Zugang beziehen.
Anzeige
Anmerkungen zum Hintergrund
Der Ransomware-Befall Ende Oktober 2023 hatte die IT von weit über Hundert Kommunen lahm gelegt – ich hatte in diversen Blog-Beiträgen wie Stillstand nach Cyberangriffen auf Kommunen in Südwestfalen und Parkhäuser in Osnabrück über den Vorfall berichtet (siehe Links am Artikelende). Zum 25. Januar 2024 liegt auch der IT-Forensik-Bericht der beauftragten Dienstleister vor und die Südwestfalen IT (SIT) hatte auf ihrer Webseite eine neue Stellungnahme mit Informationen zum Vorfall veröffentlicht. Ab 1. Februar 2024 soll ein neuer Geschäftsführer den Vorfall weiter in der Aufklärung und Behebung vorantreiben.
Ich hatte, auf Grund der öffentlich verfügbaren Informationen, den Sachverhalt in einem Blog-Beitrag (Ransomware bei Kommunal IT-Dienstleister Südwestfalen-IT; Stand Januar 2024) aufbereitet, dabei aber eine Menge Fragen aufgeworfen. Denn zu vieles von dem, was öffentlich kommuniziert wurde, passte nicht zu meinen Erkenntnissen zu bisherigen Cybervorfällen und den Informationen, die ich aus diversen Quellen zum SIT-Vorfall hatte.
Das endete damit, dass die Pressebetreuung bei mir anrief und mir anbot, den IT-Forensik-Bericht der mit der Aufklärung beauftragten r-tec IT Security aus Wuppertal zur Verfügung zu stellen. Dieser Bericht liegt mir inzwischen vor, ist aber mit vertraulich gekennzeichnet. Obwohl die Pressebetreuung der Südwestfalen IT mir keine Restriktionen auferlegt hat, möchte ich das Dokument auf Grund der Klassifizierung "vertraulich" nicht hier im Blog einstellen und auch keine Verlinkungen vornehmen (das Dokument wurde im Forum Wermelskirchen eingestellt – wird jeder bei einer Suche finden).
Angriff über VPN-Zugang
Bekannt in der Öffentlichkeit ist inzwischen, dass die Angreifer von Akira über einen "kompromittierten" VPN-Zugang Zugriff auf das IT-Netzwerk der Südwestfalen IT erhielten. Von dort konnten sich die Angreifer Administrator-Zugriff auf eine Active Directory-Domain verschaffen, die zur Verwaltung der Systemdienste benutzt wurde. Im ersten Schritt möchte ich diesen Teil des Angriffs etwas aufbereiten, da es bereits viele Details aus der Kategorie "sollte man so nicht machen" beinhaltet.
Anzeige
Angriffsversuche seit dem 18. Oktober 2023
In der öffentlichen Kommunikation heißt es, dass der "Angriff in der Nacht vom 30. Oktober 2023" erfolgte, und man dann das "sofort erkannt und die Gefahr durch Herunterfahren der Systeme gebannt bzw. durch Verhinderung der Ausbreitung eingegrenzt habe". Die mit der Aufklärung beauftragten r-tec IT Security Experten konnten den Verlauf des Angriffs aber nachzeichnen.
Von der Südwestfalen IT wurde intern Cisco ASA als Firewall-Lösung eingesetzt. Von den IT-Forensikern wurden die Protokolldateien (Logs) der Cisco ISE (steht für Cisco Identity Services Engine, die zum Identitätsmanagement genutzt wird) ausgewertet. Dabei ist festzuhalten, dass die Log-Dateien für die Analyse nur bis zum 6. Oktober 2023 zurückreichen, weil ältere Daten nach einem bestimmten Zeitraum überschrieben werden.
Bereits am 18. Oktober 2023 kam es zu auffälligen Anomalien im Login-Verhalten. Zwischen 16:25 bis 21:22 Uhr deutscher Zeit kam es über die Cisco ASA zu mehrere VPN-Login-Versuchen aus den USA an verschiedenen Konten, die dem Angreifer eindeutig zugeordnet werden können.
- Im Forensik-Bericht heißt es, dass die VPN-Anmeldeversuche teilweise fehl schlugen.
- Es gab auch Login-Versuche per VPN, die bei einem Benutzer der Domain intra.lan erfolgreich waren.
In einer stark gerafften Darstellung heißt es, dass am 18. Oktober 2023 fehlgeschlagene Anmeldeversuche per VPN von einem anonymen Nutzer auf 100 Servern in den Log-Dateien gefunden wurden. Dass SIT-Mitarbeiter eher nicht aus den USA zu arbeiten pflegen, wurde zur Erkennung dieser Login-Versuche wohl nicht ausgewertet.
Weitere Logins (ohne Sessions) gab es am 20.10, 25.10, 27.10, 28.10 und 29.10.2023. Auffällig ist, dass diese erfolglosen und erfolgreichen VPN-Anmeldeversuche aus den USA und aus anderen Ländern (Niederlande) stattfanden. Zudem lese ich, dass am 18.10.2023, zwischen 17:26 – 17:36 Uhr (also 10 Minuten) insgesamt 190 fehlgeschlagene Anonymous-SMB-Login-Versuche auf 190 Systeme in der Domäne intra.lan erfolgten. Das wäre imho eigentlich ein sicheres Zeichen für einen Einbruchsversuch, der von Sicherheitssystemen erkannt worden wäre, wenn es diese mit entsprechender Konfigurierung gegeben hätte.
Beim VPN-Zugriff am 29.10.2023 griff ein Akira-Mitglied über eine IP-Adresse aus den USA per RDP über das Active Directory-Konto intra/Administrator auf insgesamt 23 Windows Server (hauptsächlich DCs und Dateiserver) zu. Die Session dauerte vom 29.10.2023, 11:34 Uhr bis zum 30.10.2023 um 05:45 Uhr, wobei irgendwann die Verschlüsselung angestoßen wurde. Dazu möchte ich in einem separaten Beitrag was schreiben.
Unklar, wie die Anmeldedaten erbeutet wurden
Die Sicherheitsspezialisten der r-tec IT Security konnten nicht eindeutig klären, wie die Angreifer an die VPN-Zugangsdaten der Südwestfalen-IT gelangten. Die Vermutung "Phishing" konnte nach Auswertung der E-Mails nicht erhärtet werden. Zu dem in einem Medienbericht geäußerten Verdacht, dass ein Passwort "Admin123456" verwendet wurde, konnte ich im Abschlussbericht nichts finden.
Die Forensiker äußern im Abschlussbericht die Vermutung, dass der VPN-Zugang durch die Angreifer schlicht durch einen Brute-Force-Angriff (möglicherweise per Passwort-Spraying, bei der bekannte Kennwörter ausprobiert wurden) geknackt wurde. Nachdem die Angreifer Zugriff auf das IT-Netzwerk hatten, wurden weitere Schritte geplant.
In dieser Betrachtung des Ablaufs lassen sich einige Problemstellen erkennen. So war es den Angreifern möglich, aus verschiedenen Ländern per VPN auf die IT-Infrastruktur der Südwestfalen IT zuzugreifen. Auch war keine Erkennung auf Brute-Force-Angriffe vorhanden. Hier hätten entsprechende Restriktionen das Ganze zumindest schwieriger für die Angreifer machen können.
Die Forensiker halten es aber auch für möglich, dass die Zugangsdaten über eine bekannte Schwachstelle in Cisco-Produkten erbeutet werden konnte (siehe folgender Abschnitt) – bewiesen ist das aber nicht.
Domain-Administrator-Passwort in Gruppenrichtlinie
Unklar ist mir auch, warum Administrator-Konten per VPN aufgerufen werden können und warum diese nicht besonders gesichert wurden (z.B. Authentifizierung über Zertifikate , MFA). Und wieso konnte jemand sich mit einem VPN-Zugang im Netzwerk unter neuen Benutzern an anderen Konten anmelden. Zero-Trust wurde da innerhalb des SIT-Netzwerks sehr speziell interpretiert – "wer drin ist, dem vertrauen wir", und weil das so ist, wurde noch ein besondere Schmankerl im Abschlussbericht offen gelegt.
Das oben erwähnte Administrator-Passwort ist im Bericht zwar nicht aufgeführt. Aber die Sicherheitsexperten stellten fest, dass das Kennwort des Domänen-Administrators intra.lan\Administrator seit 2014 in einem Gruppenrichtlinienobjekt in entschlüsselbarer Textform hinterlegt war. Lässt sich leicht durchführen, und wer das Passwort kennt, kann sich zum Domain-Administrator mit allen Rechten machen.
Es kann also sein, dass durch den Angriff vom 18. Oktober 2023 bereits genügend Daten gesammelt worden waren, um später per VPN-Zugang auf das Domänen-Administrator-Konto zuzugreifen. Diese Rechteausweitung ist dann forensisch nicht nachweisbar.
Problem mit Sicherheitslücken
Im Rahmen der Analyse stellte sich auch heraus, dass die Südwestfalen IT ein massives Problem mit ungepatchten Cisco-Systemen hatten. In meinem Beitrag Ransomware bei Kommunal IT-Dienstleister Südwestfalen-IT; Stand Januar 2024 heißt es zwar (ich hatte mich auf öffentliche Informationen bezogen), dass es 0-day-Schwachstellen gegeben habe. Das ist so aber nicht ganz korrekt.
Dazu muss man wissen, dass es zum 6. September 2023 von Cisco das Security Advisory Cisco Adaptive Security Appliance Software and Firepower Threat Defense Software Remote Access VPN Unauthorized Access Vulnerability veröffentlicht wurde. Dort wurde vor der Schwachstelle CVE-2023-20269 gewarnt, und es hieß: Eine Schwachstelle in der Fernzugriffs-VPN-Funktion der Cisco Adaptive Security Appliance (ASA) Software und der Cisco Firepower Threat Defense (FTD) Software könnte es einem nicht authentifizierten, entfernten Angreifer ermöglichen, einen Brute-Force-Angriff durchzuführen. Dies ermöglicht es, gültige Kombinationen aus Benutzernamen und Passwort zu ermitteln, oder einem authentifizierten, entfernten Angreifer, eine clientlose SSL-VPN-Sitzung mit einem nicht autorisierten Benutzer aufzubauen.
Von Cisco wurden Sicherheitsupdates veröffentlicht – das Problem mit der Schwachstelle war also am 6.9.2023 behebbar. Ein Blog-Leser hat mich zudem auf einem Artikel CVE-2023-20269: Zero-Day Vulnerability in Cisco Adaptive Security Appliance and Firepower Threat Defense Reportedly Exploited by Ransomware Groups von Tenable hingewiesen, der auch im Abschlussbericht erwähnt wurde. Zum 11. September 2023 wiesen die Tenable Sicherheitsforscher auf den Patch von Cisco hin und schrieben, dass die Schwachstelle durch Ransomware-Gruppen ausgenutzt wurde.
Zusammenfassung der Erkenntnisse
Nur fürs Protokoll: Am 18. Oktober 2023 haben die Angreifer dann mal bei der Südwestfalen IT vorbei geschaut. Danach gab es einige "Besuche" und am 29./30. Oktober 2023 das "Abschiedskonzert". Der obige Abriss verdeutlicht bereits, wie problematisch die Sicherheitsstrukturen bei der Südwestfalen IT waren und einfach die Angreifer es hatten – nachdem diese in etwa die Struktur verstanden hatten.
Der Abriss verdeutlicht auch, warum so Dinge wie der Defender oder irgendwelche Sicherheitssysteme nicht anschlugen. Die Sicherheitssysteme waren nicht darauf ausgelegt, einen Angreifer, der den VPN-Zugang überwunden hat, zu erkennen und abzuweisen. Und der VPN-Zugang war gegenüber Brute-Force-Angriffen oder Zugriffen aus dem fernen Ausland nicht abgesichert.
Hinter dem VPN fungierte das Südwestfalen IT-Netzwerk sozusagen als "Trusted Zone" – wenn Du drin bist, darfst Du erst einmal alles tun, wir haben ja noch die Passwörter im Active Directory, um Konten zu schützen. Und wie will man schon ein Passwort für den Domain-Administrator finden, wenn das in Millionen Bytes und Gruppenrichtlinien versteckt ist – die Nadel im Heuhaufen findet niemand …
In einem weitere Teil möchte ich auf weitere Punkte wie die Bewegung der Angreifer in der Domäne oder die Frage, warum die Angreifer wohl keine Daten vor dem Verschlüsseln abziehen konnten, eingehen.
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
Cyber-Security II: IT-Planungsrat empfiehlt Kommunal-IT von NIS-2-Richtlinie auszunehmen
NIS-2-Richtlinie muss bis 17. Oktober 2024 von (betroffenen) Unternehmen umgesetzt
Schwedisches Rechenzentrum des finnischen Cloud-Anbieter Tietoevry per Akira-Ransomware lahm gelegt
Warnung vor Schwachstellen; Fortinet, Ivanti und mehr (Januar 2024)
Anzeige
sehr schön dass das so ausführlich berichtet wurde.
Was mich wundert, dass es einen Account namens "Administrator" gegeben hat.
Meines Wissens ist dieser seit Jahrzehnten deaktiviert und Microsoft rät, diesen Account nur als Boobie trap einzusetzen um evtl. Angriffe sofort zu erkennen.
Auch ist die Diskussion da, das Admin Zugänge nicht durch Fehlversuche gesperrt wurden…
Resi. der Fehlversuch Zähler durch einen erfolgreichen einlogg Vorgang oder Zeitablauf zurückgesetzt wurde. Was natürlich spraying erleichtert(man man 2 Fehlversuche, wartet den nächsten Tag ab bis der Legitime User sich ganz normal angemeldet hat und hat am Abend wieder 2 Schuss frei. Früher wurden die User ja beim Login noch mit Werten wie "Ihr letzter Login Versuch erfolgte von geknackt.us und war zweimal erfolglos" überlastet oder zu Rückfragen beim Admin führten…
Wenn ich mich bei Amazon aus dem Ausland anmelde bekomme ich sofort eine Email mit der IP meines Hotels nebst Geodaten… melde ich mich nicht, wird mein Account gesperrt auch wenn es in der Email anders stand.
aber hier passiert nichts?
Das mit der Mailbestätigung bei erfolgreicher Anmeldung kennt man ja von verschiedenen Onlinediensten usw., aber das für eine VPN-Verbindung zu nutzen, finde ich cool. Die Umsetzung wird aber wahrscheinlich je nach verwendeter VPN-Lösung unterschiedlich komplex. Das Problem ist nur, wer ließt diese Mail mitten in der Nacht oder am Wochenende, wenn sein Account gerade missbraucht wird? Außerdem, wenn der Angreifer mit einem AD-Account einloggt, hat er auch Zugriff auf die Mail und kann sie selbst bestätigen.
Ja, das Problem besteht auch bei der Amazon Nachricht, das ich sie nicht lesen oder der Angreifer sie beantwortet.
Es passieren dann auch noch andere Sachen.
Z.B. kann ich nur noch mit der Zahlweise "Gutschein" bezahlen. Besorg mal im Ausland Gutscheine…
Ich bekomme auch von Google sofort eine Email, wenn ich mich mal per Freifunk anmelde und dann irgendwo aus einem VPN im Ausland ins Netz gehe.
Das ist alles keine Raketen Wissenschaft.
Aber es ist sehr aufwendig.
und dann ist da noch das böse Dreieck zwischen Kosten Komfort und Sicherheit.
Also wenn ich gemütlich geschlafen habe, und am morgen eine E-Mail bekomme, ich hätte mich mitten in der Nacht aus USA versucht anzumelden oder angemeldet werde ich als User schon wach.
Natürlich werden ggf. auch näher gelegene IP Adressen als Proxy für einen Angriff genutzt..
Aber ich weiß ja, das ich im Hotel Vierjahreszeiten war.
Natürlich muss man dafür sorgen, das der User nicht ständig solche E-Mails bekommt…
Nee, der Account "Administrator" ist nicht deaktiviert, sondern standardmäßig immer aktiviert, denn wenn man ein System neu aufsetzt, muß man ja irgendwie da rein. Und das geht über den Administrator-Account.
Und der hat auch immer die gleiche SID, über den er sich erkennen lässt. Deshalb reicht auch ein Umbennen alleine nicht aus.
Deshalb ja die Ratschläge von Microsoft, neue Accounts (und nicht nur einen, der alle Rechte des deaktivierten Administrator-Accounts hat, auch wenn das bequem erscheint, sondern für jede Aufgabe getrennte Accounts mit nur den jeweils nötigen Rechten. Zudem sollten die Accountnamen NICHT auf die Funktion des Accounts hinweisen.) anzulegen und den Account "Administrator" sowohl umzubenennen als auch zu deaktivieren.
Zudem sollte der Account und auch andere administrative Accounts niemals eine E-Mail Adresse haben, also im Exchange die Accounts gleich raus werfen.
Im AD sollte auch eingestellt sein, zu welchen Uhrzeiten und an welchen Wochentagen man sich anmelden kann.
Nämlich nur zu normalen Geschäftszeiten.
Außerdem, von welchen Systemen man sich anmelden darf.
Mit administrative Accounts sollten man sich nie von anderen Systemen als denen der IT-Abteilung anmelden können.
Hier kommen wohl verschiedene Faktoren zusammen.
Meine Vermutung: Die haben ihre Systeme nicht auf dem aktuellen Patchstand gehabt und die Angreifer haben eine nicht gepatchte Sicherheitslücke ausgenutzt. Zudem gabs noch diverse andere administrative Fehler. Einige wurden ja genannt, wird wohl nicht das Ende der Liste gewesen sein.
Ein Klopper ist, das Adminkennwort irgendwo im Klartext abzulegen.
Warum nicht gleich an die Firmenpinnwand heften?
Hat den gleichen Effekt.
Dieser Vorfall zeigt, wie wichtig es ist, Patche so zeitnah wie möglich einzuspielen. Zur Not muß die IT dann eben mal Überstunden schieben, um die Patches außerhalb der normalen Geschäftszeiten einzuspielen.
Da wurde wohl ein ganzer Haufen administrativer Fehler gemacht.
Es handelte sich hier nicht um den lokalen Administrator des Systems, sondern den Domänen-Administrator INTRA\Administrator.
Es ist nicht angegeben, wie alt diese Domäne ist (möglicherweise schon unter Windows 2000 mit den damals gültigen Defaults angelegt) und ob beim Hochstufen auf den aktuellen Stand jeweils immer der gesamte Sicherheitsleitfaden von Microsoft abgearbeitet wurde.
Das Kennwort wurde wohl in einer Gruppenrichtlinie hinterlegt (laut Bericht galten Gruppenrichtlinien immer für die ganze Dömäne) und auch nicht im Klartext, wohl aber in entschlüsselbarer Form, da es vermutlich zur Konfiguration einzelner Dienste auf den Servern bekannt sein mußte.
Laut "Incident-Management-Timeline" des r-tec-Berichts wurden am 30.10.2023 in der Zeit von 2:00 Uhr bis 6:30 Uhr
– sämtliche Server der SIT heruntergefahren
– die Verbindung zu Kunden gekappt
– die Internetverbindung gekappt.
Von daher ist es müßig, über eine mobilen oder oder immobilen Standort der Abfrage zu sinnieren, oder ob der Zugriff über statische oder dynamische Adressen erfolgte.
Es geht um die oben ausgesprochene Empfehlung, Verbindungen nur zu "normalen Geschäftszeiten" (welche sind das denn bei der Polizei?) und geographischer Begrenzung (wie wir wissen setzt die Polizei bei Großereignissen auch mobile Büros im VW-Bus ein, die vermutlich keine fixe IP (falls überhaupt IPv4) im Mobilfunknetz haben) zuzulassen.
Ansonsten müßten ja alle, die z.B. in der Silvesternacht festgenommen wurden, bis 2.1. 09 Uhr warten, ehe eine "Überprüfung der Identität" vorgenommen werden kann.
Geographische Begrenzung geht rel. einfach.
Einfach nur Zugriffe gestatten von IPs, die Deutschland zugeordnet sind.
Damit inkludiert man auch mobile Büros, sofern die über einen Zugang in Deutschland eingewählt sind.
Ich sehe übrigens nicht, das die Polizei Dienste der SIT nutzt.
Damit könnte man es regional sogar noch weiter eingrenzen.
"Ich sehe übrigens nicht, das die Polizei Dienste der SIT nutzt."
Ich zitier mal aus einem der ersten Beiträge von G.B. zu dem Cybervorfall:
"… dass der Cybervorfall erst auffiel, als eine Polizeiabfrage Montag-Nacht um 2:00 Uhr scheiterte, weil nichts mehr ging. …" .
Das ist schon klar.
Das, was ich geschrieben habe, gilt auch und insbesondere für den Domänen-Administrator, siehe Microsoft Richtlinien.
Es wurde festgestellt, daß das Gruppenrichtlinienobjekt mit dem Kennwort zuletzt 2014 geändert wurde, was nahelegt, daß die Domäne vor mindestens 10 Jahren nach den damaligen Empfehlungen (möglicherweise Server 2012 oder 2008R2, denkbarerweise aber auch 2000 oder 2003) erzeugt wurde.
Ja, und auch damals schon gabs die Empfehlung.
Ich habe hier mit Windows 2000 (bzw. sogar schon mit NT 4 Server, aber da gabs noch kein AD) angefangen und schon damals habe ich den Domänen-Admin Account deaktiviert.
Und das ist er bis heute.
Viele Microsoft-Richtlinien sind schon uralt!
Aber manche Richtlinien überholen sich auch mit der Zeit. Daher heißt es immer, am Ball bleiben.
Regelmäßig schauen, ob sich Richtlinien geändert haben, neue hinzugekommen sind, etc.
Moin,
wo steht denn, daß es sich um einen "Administrator" handelt? Nur weil das steht daß ein Benutzer aus der der Domäne "intra-lan" beteiligt war?
Das ist ein Bericht einer Firma, die die Umstände des Zugriffs aufklären soll bzw. schon in Teilen hat. Daß dabei keine echten Benutzernamen verwendet werden, dürfte klar sein, genauso, daß die beteiligten IP-Adressen verschleiert wurden.
Ich lese daraus, daß dort ein Mitarbeiter/Benutzer mit Administrator-Berechtigungen, der auf der Domäne "intra.lan" angelegt ist, beschrieben wird. Und ob der Benutzer nun "Administrator" heißt oder er nur die entsprechenden administrativen Berechtigungen innehat, ist zunächst mal für den weiteren Ablauf unerheblich.
Aus dem Bericht geht nur hervor, der der Cyber-Angriff über einen Benutzer-Account mit administrativen Rechten erfolgt ist. Eine genaue Definition, welcher Account das war, ist aus dem Bericht nicht zu entnehmen.
Ebenso ist die Feststellung, daß ein Paßwort "admin123456" bei der SIT benutzt worden sein soll, durch den Bericht nicht bestätigt worden.
Richtig – alle IP-Adressen und Benutzerkontennamen sind geschwärzt – im Text ist dann von Konto oder Administratorkonto für die Rede.
Nicht ganz, INTRA\Administrator (und dass das das Konto ist, das in der GPO steht, s. Seite 24) steht an mehreren Stellen ungeschwärzt im Bericht. Die "normalen Enduser", deren Konten vermutlich durch unsicheres Passwort per VPN-Bruteforce geknackt wurden, diese sind geschwärzt, um sie nicht öffentlich bloßzustellen.
Hochinteressant, auch wenn es nicht so in die Details gehen kann, danke!
Solche Bruteforce-Attacken auf ein Gateway zu erkennen und abwehren, ist nicht ganz leicht, weil die Angreifer schnell merken, wenn ein Intrusion-Detecion-System anwesend ist, welches bei zu vielen Versuchen pro Zeiteinheit Alarm schlägt und vielleicht sogar entweder automatisch oder manuell Gegenmaßnahmen wie Angreifer-IPs sperren ausgeführt werden. Die verändern dann ihr Verhalten, wenn sie noch genug andere IPs als Reserve haben. Ich habe da schon alle möglichen Muster ausgewertet, angefangen von vielen Versuchen mit immer den selben oder unterschiedlichen (einfallslosen) Benutzernamen wie "admin", "test", "vpnuser", "business", … von immer der selben IP-Adresse oder den selben Nutzernamen verteilt über dutzende bis hunderte verschiedenen IP-Adressen aus verschiedenen Ländern und Providern. Wenn man die IP-Adressen dann einem gemeinsammen Angriffsversuch (z.B. durch gleich verwendete Usernamen) zuordnen kann, kann man die Angreifer immerhin mit Abuse-Mails an die Provider teuer treffen, wenn die Provider tatsächlich einen Takedown vieler Server veranlassen. Aber auch das gegenteilige Angriffsmuster kann sein, nur eine Hand voll Loginversuche über den ganzen Tag verteilt, vielleicht mit schlaueren Benutzernamen, vielleicht nach den häufig verwendeten Mustern v.nachname, vnachname, vorname.nachname, usw., vielleicht aus Recherche von Mitarbeiternamen. Man muss da die Erkennungsregeln ständig nachschärfen und selbst das hilft nicht zuverlässig, besser manuell nochmal nachschauen… Da rettet einem den Ar*** nur noch, wenn man ausreichend komplexe Passwörter, eine Vermeidung von komprmittierten Passwörtern und eine 2-3-Faktorauthentifizierung hat.
Ich bin auf die Fortsetzung gespannt!
Generell kann man auch die Angriffsfläche verkleinern.
Z.B. das VPN außerhalb der normalen Arbeitszeiten abzuschalten. Was hier ja kein Problem gewesen wäre.
Und natürlich die IP begrenzen die man rein lässt.
(Wer ins VPN rein will, muß z.B. erstmal eine Website abrufen. Erst dannach reagiert das VPN auf Anfragen und nur von dieser IP. Port Scans von irgendwelchen IP würden nichts Attraktives zeigen.)
Hier waren es ja klare Verhältnisse wo,wer,wann und nicht irgendwie Reisende, die täglich eine andere IP haben.
MFA hilft aber nicht, wenn die Rechner der Kunden infiziert sind…
Das erste Anzeichen für die Störung war eine fehlgeschlagene Anfrage der Polizei nach einer Meldeadressen am 30.10. gegen 02:00. Ob das von einem Fahrzeug oder einer Polizeidienststelle aus erfolgte und ob diese eine statische oder dynamische IP-Adresse verwendete ist leider nicht angegeben.
Moin,
>>Z.B. das VPN außerhalb der normalen Arbeitszeiten abzuschalten. Was hier ja kein Problem gewesen wäre.<<
Grandiose Idee! Du hast noch nie in einer Kommunalverwaltung gearbeitet, stimmts?
Mal folgendes Szenario, daß gar nicht mal so selten auftritt:
Es steht eine Ratssitzung an, die ab 19:00 Uhr beginnen soll, also außerhalb der oben postulierten normalen Arbeitszeiten. Aus Platzgründen findet die Sitzung nicht im Ratssaal im Rathaus statt, sondern in einem Saal in einem der Ortsteile. Während der Sitzung wird der Bürgermeister nach Daten gefragt, die mit dem eigentlichen Thema nichts zu tun haben, aber für den weiteren Verlauf der Sitzung doch wichtig sind. In dem besagten Saal ist eine WLAN-Verbindung und da der Bürgermeister seinen Dienstlaptop mit den für die Sitzung benötigten Daten dabei hat und er den auch privat benutzen kann (BYOD), will der sich "mal eben" per VPN in seinen Account bei der Kommune einloggen. Geht nicht, weil der Admin ja die zeitliche Sperre gesetzt hat. Jetzt gibts zwei Möglichkeiten: der Bürgermeister eilt stehenden Schrittes zum Rathaus, loggt sich dort mit seinem Laptop ein und zieht die benötigten Daten auf seinen Laptop oder druckt sie aus. Während dieser zeit drehen die übrigen ratsmitgliedr, die jeder noch einen eigentlichen Beruf haben, Däumchen und warten. Oder aber die Sitzung wird vorzeitig beendet und ein neuer Termin wird vereinbart.
Was glaubst Du, was Du am nächsten Morgen als erstes tun wirst? Richtig: Auf Anweisung vom Bürgermeister wirst Du diese zeitliche Einschränkung wieder entfernen! Eine Abmahnung und damit ein Eintrag in die Personalakte ist damit obligatorisch und mit den "Altlasten" hast Du erstklassige Möglichkeiten, einen anderen Job zu bekommen. Im kommunalen Bereich aber auf jeden Fall nicht mehr, denn jeder neue Chef wird den alten Chef fragen, warum und wieso Du nicht mehr da bist.
Und das ist nur ein Beispiel, bei dem die Kommune selbst betroffen ist. In dem Beitrag von G.B. und auch im Kommentar von Fritz kommt die Passage vor, daß der Zugriff auf die kommunalen Daten durch die Polizei nicht möglich war. Wie greifen die wohl auf die Daten zu? Oder die Feuerwehr, wenn ein mehrstöckiges Haus brennt? Oder der Rettungsdienst, wenn eine Adresse gefunden werden muß? Diese Anfragen laufen alle ins Leere, weil der Admin ja die zeitliche Begrenzung für den Zugang eingerichtet hat und Vorfälle, in denen der oben genannte Personenkreis Zugriff benötigt, gefälligst alle während der normalen Dienstzeit zu geschehen haben.
Willkommen im richtigen Leben!
Ich kann mir gut vorstellen dass man das VPN nicht in einer DMZ termiert, wie es sich gehört, sondern direkt im LAN.
Es ist ja viel einfacher zu verwalten und wenn ein User sein Notebook in der Firma im LAN anmeldet oder vom Hotel oder Home Office per VPN sieht für ihn alles gleich aus.
Und natürlich nimmt man für die VPN due Anmeldung aus dem AD und macht gleich SSO. So wird der interlektuell hochstehende Cheffe nicht mit 2 Passwörtern genervt. Ich würde mir noch ein Port knocking wünschen, aber…
Am Anfang des Berichtes geben die Forensiker einen Überblick über die vorgefundene Netzwerkstruktur.
Die Kompromittierte Dömäne "intra.lan" ist nur eine von mehreren und dem Kunden "Kommunen in NRW" zugeordnet. Dort waren wohl auch nur 770 Server (vermutlich Gastsysteme der Virtualisierungsinfrastruktur) und 4176 Clients (vermutlich virtuelle Desktops) angesiedelt.
Andere Kunden (z.B. citkomm oder kdvz) und auch die intern genutzte Domäne "sit.dl" waren davon getrennt bzw. nur über Domänenvetrauensstellungen erreichbar, ebenso die 320 Server in der DMZ.
So wurde auch ein Übergreifen auf die Virtualisierungsinfrastruktur vermieden, die Angreifer bemühten sich ja um einen Zugriff auf VEEAM um gemäß normaler Vorgehensweise auch die Backup2Disk-Repositories zu löschen, das scheiterte aber, so daß eine schnelle Wiederherstellung auf einen Punkt vor dem ersten nachweisbaren Zugriff möglich wurde.
Gemäß Bericht wurden ja auch nur 2 Tage Forensik (der teuerste Teil der Dienstleistung) durchgeführt und viele Bereiche, die nicht unmittelbar betroffen waren ausgespart.
Anschließend wurden Maßnahmenempfehlungen gegeben (was Du oben schreibst ist da auch mit enthalten) die kurz- bzw. mittelfristig umgesetzt werden sollen, wenn das Personal der SIT die Systeme (unmittelbar betroffen waren weniger als eintausend) neu aufsetzt und die Kommunen zum Nachpflegen der zwischenzeitlich aufgelaufenen Daten bittet.
Ich weiß, weswegen ich Windows-Systeme noch nie mochte und lieber mit GNU/Linux arbeite: Der eklatante Vorteil ist das Logging im Klartext und die Möglichkeit, sich mit "Bordmitteln" und entsprechender Konfiguration durch Filterung und Reduktion auf das Wesentliche ("logcheck"), über alle Arten von "Anomalien" per Mail benachrichtigen zu lassen, während Windows-System zwar Unmengen loggen, aber die Meldungen oftmals überflüssig und für Menschen wenig interpretierbar sind. Solche fehlgeschlagenen Anmeldeversuche würden erkannt und gemeldet und gleichzeitig mit einem weiteren Programm ("fail2ban") abgewehrt.
Dass die Angriffe aus den USA möglich waren, ist allerdings nicht ungewöhnlich, denn ein VPN soll für "Road-Warrior" schließlich weltweit zugänglich sein. Geoblocking wäre also unangebracht. Für Admin-Zugänge würde ich allerdings ein extra VPN mit Geoblocking empfehlen.
Nein, ein VPN soll nicht von überall zugänglich sein. Es ist natürlich einfacher zu verwalten, aber sicherheitstechnisch sollte man das auch einschränken. Jeder kleine Einfallsvektor kann und sollte vermieden werden. Vorallem öffentlichen Betrieb. Jeder hat doch nur auf "mit Linux wäre das nicht passiert" gewartet. Was hätte dir das Logging im Klartext gebracht? Nichts.
Also falls es in deren AD eine alte GPO mit einer GPP gab, in der jemand irgendwelche Administrator Credentials direkt zur Verwendung eingetragen hat, dann wäre das schon schlecht.
Solche Anmeldedaten sind i.d.R. für alle AuthenticatedUsers im Sysvol auslesbar und ohne Aufwand mit dem bekannten AES Key (z.B. via Get-GPPPassword) rückwärts entschlüsselbar.
Contryblocking der IP-Ranges der ganze Erde, ausgenommen der BRD :-)
Btw: Die Firewall der QNAP Nas hat neuerdings auch schon C. aber die sollte man auch nur noch per VPN erreichbar machen.
Erst vor kurzem den Kunden übernommen, bei dem der interne ITler in Ruhestand gegangen ist. Naja was soll ich sagen RDP direkt nach außen offen, DC auf 2008R2, Exchange 2007 mit OWA nach außen, Firewall hat schon seit 4 Jahren keine Updates mehr gesehen, keine Gruppen im AD und alle Benutzer in der Defaultuser-Gruppe, alles mit Druckeranbindung, Netzlaufwerke über irgendwelche Batchscripte eingebunden und zu guter Letzt das Domäneadminpasswort im Klartext in einem der Scripte, zwar vSphere, aber kein wirkliches Backup, sondern nur täglich ein RSync wichtiger Dateien auf den Backupserver. Über 25 Jahre gewütet und niemals irgendwelche externe eingebunden gehabt, geschweige den Audits. Ich habe somit alles gesehen wie man es nicht machen sollte.
Eine schöne (ernst gemeint) und spannende Aufgabe. Ich kann mir zwar in Grenzen meine Themen auch selbst aussuchen, bin aber oft Sklave der bestehenden Hardware und Umgebung.
Ein paar (unverbindliche – entscheiden mußt letztendlich Du) Tipps:
1. Du mußt die User mitnehmen.
Die Beschreibung der Umgebung läßt mich vermuten daß auch ein Teil der noch vorhandenen Anwender gesetzteren Alters ist und jede Komforteinschränkung oder Abweichung vom gewohnten Prozedere (sei es 2FS, komplexe Paßwörter oder die Komforteinschränkung, nicht mehr alles sofort oder von jedem Ort der Welt aus tun zu können) als Affront sehen.
Wenn da zuviel Affront kommt kann es sein, daß Du scheiterst, obwohl Du (technisch) eigentlich alles richtig gemacht hast, aber den Sündenbock spielst.
2 Analysiere gründlich
Gerade in den x verteilten Scripten kann noch jede Menge subtiler Abhängigkeiten und Gemeinheiten stecken – selbst wenn Du glaubst schon alles verstanden zu haben. Wenn das Ganze 25 Jahre gut gegangen ist, kann es auch noch ein paar Tage so laufen bevor Du substanziell eingreifst.
Platziere am Besten an wichtigen Stellen eine Reihe NextGen-Firewalls im Beobachtungsmodus (die gibt es auch virtuell unter vSphere ond oft die ersten 30 oder 60 Tage kostenlos) und schaue erst mal, welche Kommunikation stattfindet und wofür die wirklich gebraucht wird. Dann kann man Schritt für Schritt für diese Services eine Lösung finden, ohne daß einem bestehende Funktionalität um die Ohren fliegt.
3. Kläre die Kostenfrage
Dein Gehalt ist sicherlich eingepreist, aber vermutlich damit auch die Erwartungshaltung verknüpft, daß ab sofort alles besser wird.
Die Beschreibung oben läßt mich vermuten, daß allein schon bei den Bestandslizenzen für vSphere, Veeam und Windows (Server und Clients, auch 7->10 ist nicht mehr kostenfrei) größere Investitionen erforderlich sind, zusätzlich noch die eine oder andere Neuanschaffung (Firewalls, Storage, Datensicherung…). Prüfe auch, ob der Laden nicht vielleicht unterlizensiert ist (gerade bei Windows CALs geht das sehr schnell, weil sie eben wirklich nur auf Papier stehen). Nichts ist schlimmer, als wenn das Management auf halbem Wege die Reißleine zieht.
4. Mach realistische Zeitpläne
Auch wenn das ein spannendes Thema ist, achte darauf daß es nicht zur Selbstausbeutung und einer Beschäftigung 24/7 wird, das hält kein Mensch endlos durch. Auch Hardwarebeschaffung kann in der aktuellen Lieferkettensituation zäh werden.
Ansonsten wünsche ich viel Erfolg und Freude (ernst gemeint) mit dieser Aufgabe.
Kurz & knackig: https://blog.fefe.de/?ts=9b4d72e1