Im Beitrag Ransomware bei Kommunal IT-Dienstleister Südwestfalen-IT: Nachlese IT-Forensik-Bericht Teil 1 hatte ich ja skizziert, wie die Ransomware-Gruppe Akira bei ihrem Angriff vom Oktober 2023 auf die Südwestfalen IT (SIT) vorgegangen ist, um per VPN in das Netzwerk des Kommunal-IT-Dienstleisters einzudringen. In Teil 2 gehe ich auf Fragen ein, die sich aus dem weiteren Verlauf des Angriffs ergeben. So liefert der Forensik-Bericht Hinweise, was weiter bei der SIT schief lief, und warum die großes Glück hatten, dass vermutlich keine Daten abgezogen und nur Systeme innerhalb einer Domäne verschlüsselt wurden.
Anzeige
Vorgehensweise von Akira bestätigt
Geht man in Quellen wie diesen Sophos-Bericht oder diesen Trellix-Artikel, die sich mit den Aktivitäten der seit Anfang 2023 auftretenden Ransomware-Gruppe Akira befassen, werden die Erkenntnisse aus dem Beitrag Ransomware bei Kommunal IT-Dienstleister Südwestfalen-IT: Nachlese IT-Forensik-Bericht Teil 1 bestätigt. Die häufigste Art des Erstzugriffs, die von Akira-Ransomware-Akteuren bisher genutzt wurde, ist die unbefugte Nutzung von VPN-Zugängen durch kompromittierte Konten ohne Multi-Faktor-Authentifizierung (MFA). In der Regel beobachtete Sophos, dass Akira-Akteure speziell auf Cisco VPN-Produkte ohne aktivierte MFA abzielten, wie z.B. Cisco ASA SSL VPN oder Cisco AnyConnect.
Neben dem Fehlen von MFA nutzen Akira-Akteure auch bekannte Schwachstellen in der VPN-Software selbst aus. Im SIT-Fall vermutlich die Sicherheitslücke CVE-2023-20269 im Cisco ASA des Unternehmens aus, um eine nicht autorisierte VPN-Sitzung mit Fernzugriff auf die Infrastruktur des Opfers aufzubauen. Aber auch das Abfischen von Zugangsdaten per Phishing oder der Aufkauf von geleakten Zugangsdaten im Darknet sowie Brute-Force-Angriffe auf Konten ohne 2FA gehören zum Repertoire der Gruppe. Im Beitrag Wenn Ransomware-Gruppen Sicherheitstipps geben habe ich Sicherheitstippe der Gruppe gegenüber einem (zahlenden) Opfer aufgelistet.
Alle diese Informationen passen genau auf die Erkenntnisse des Akira-Angriffs auf die Südwestfalen IT. Ob eine Multifaktor-Authentifizierung (2FA) der VPN-Zugänge den Angriff verhindert hätte, bleibt unklar. Fefe weist in diesem Beitrag mit Recht darauf hin, dass sich 2FA ebenfalls aushebeln lässt. Das wäre durch kompromittierte Mitarbeiter-Systeme, 2FA-Fatigue oder Abfischen von Zugriffstokens über Schwachstellen möglich.
Problem: Fehlende Logs
Ein Punkt, der mir beim Lesen des Forensik-Berichts aufgefallen ist, besteht darin, dass zur Analyse vielfach Protokolldateien (logs) fehlten. Das beginnt mit dem Umstand, dass ältere Log-Dateien vor dem 6. Oktober 2023 bereits überschrieben worden waren (der Angriff wurde ja am 30. Oktober 2023 bemerkt), oder Zugriffe erst gar nicht protokolliert wurden. Hier verweise ich auf meinen erst kürzlich im Blog veröffentlichten Artikel Leitfaden zur Konfigurierung der Windows Event-Protokollierung. Der Beitrag thematisiert einen Leitfaden des australischen Signals Directorate (ASD) und des Australian Cyber Security Centre (ACSC). Dieser Leitfaden gibt Hinweise für die Konfiguration der Windows-Protokollierung, um mehr Informationen, auch bei Cybervorfällen zu bekommen.
Anzeige
Sicherheitssoftware und Virenscanner scheitern
Viele Stellen verlassen sich darauf, dass vorhandene Sicherheitssoftware und Virenscanner wie der Microsoft Defender einen Angriff erkennen und stoppen. Schlagworte wie Intrusion Detection, Ransomware-Protection etc. machen die Runde. In der Forensik-Analyse findet sich ein Hinweis auf "Symantec-Encryption-Meldungen", was ich so interpretiere, dass eine Sicherheitslösung von Symantec die Verschlüsselung zwar bemerkte, aber nicht stoppte, sondern nur protokollierte.
Auch die über 300 fehlgeschlagenen Anmeldeversuche an VPN-Konten binnen kurzer Zeit wurden nicht als Angriff erkannt, sondern nur protokolliert. Bezüglich Virenschutzlösungen ist anzumerken, dass diese oft nutzlos sind. In diesem Sophos-Artikel zu Akira findet sich der Hinweis, dass bei Angriffen auf Unternehmen mit Sophos Endpoint-Schutz wiederholt beobachtet wurde, dass die Angreifer versuchten, den Sophos-Schutz zu deinstallieren und/oder zu deaktivieren, um die Erkennung zu umgehen.
Im Fall der Südwestfalen IT war zwar der Windows Defender als Schutz vor Schadsoftware vorhanden. Aber ein PowerShell-Befehl reichte den mit Administratorrechten operierenden Angreifern, um die Partition des logischen Laufwerk C:\ von Scans auszunehmen. Ab diesem Zeitpunkt war der Defender "blind" und die Malware w.exe ließ sich im Anschluss unerkannt auf verschiedenen Systemen platzieren.
Der Domänenadministrator darf alles
Die Angreifer waren, nachdem sie über VPN-Verbindungen auf das Netzwerk zugreifen konnten, in der Lage, das Konto eines Domänenadministrators zu nutzen. Bereits in Teil 1 hatte ich erwähnt, dass das Kennwort für das Konto intra.lan\Administrator vermutlich aus einem Gruppenrichtlinienobjekt (wo es 2014 abgelegt wurde) extrahiert werden konnte. Ein Nachweis lässt sich laut Forensik, mangels fehlender Logs oder Spuren, aber nicht führen.
Aus dem Bericht geht hervor, dass beim koordinierten Angriff über vier gleichzeitig aufgebaute VPN-Sessions am 29. Oktober 2023 die Angreifer genau wussten, was sie wollten. Eine Minute nach dem Aufbau der VPN-Sitzungen fand der erste RDP-Zugriff unter Verwendung des Benutzers intra.lan\Administrator auf einen Domänencontroller statt.
Ab da begann sozusagen das "Gemetzel" denn die Hacker griffen im Anschluss auf 22 weitere Systeme (überwiegend ebenfalls Domänencontroller) zu. Die Analytiker klassifizieren dies als koordiniertes Vorgehen eines länger vorbereiteten Angriffs. Durch das verwendete Konto des Domänen-Administrators gibt es auch keine Spuren im Hinblick den Weg zur auf Rechteauswertung. Der Forensik-Bericht erwähnt zwar weitere Schwachstellen, die ebenfalls eine Erhöhung der Berechtigungen zum Domänen-Administrator ermöglicht haben könnten. Allerdings haben die Analytiker keine konkreten Anzeichen einer Ausnutzung durch die Akira-Gruppe finden können.
Pech für Akira, Glück für die SIT
Was ich aus dem Untersuchungsbericht auch herauslese, ist, dass die Südwestfalen IT an einigen Stellen (trotz gravierender Mängel) einfach riesiges Glück hatte und der Angriff begrenzt blieb. Der Schaden für die betroffenen Kommunen und der Reputationsverlust der SIT ist zwar immens. Aber die Angreifer von Akira hatten an einigen Stellen einfach Pech bzw. die SIT hatte Glück.
WinRAR-Aufruf scheiterte – wohl keine Daten abgezogen
Normalerweise versuchen Ransomware-Gruppen vor dem Verschlüsseln Dateien von den Systemen der Opfer abzuziehen, um diese später ggf. mit deren Veröffentlichung erpressen zu können. Die Forensiker stellten aber fest, dass der Versuch der Angreifer, das Programm WinRAR von einem File-Server aufzurufen, scheiterte. Damit fehlte wohl die Möglichkeit, Dateien zu kompromittieren und an Server des Angreifers zu übertragen. Bei der forensischen Untersuchung und im Nachgang zum Ransomware-Fall wurden bisher keine Hinweise auf abgezogene Daten gefunden – obwohl das natürlich nie mit Sicherheit auszuschließen ist.
Veeam-Zugangsdaten nicht auslesbar
Die Forensiker stellten den Versuch der Angreifer fest, die Zugangsdaten der für Backup-Zwecke verwendeten Veeam-Lösung per PowerShell auszulesen. Dies hätte die Möglichkeit eröffnet, Backups ggf. abzuziehen und im Anschluss die Sicherungen auf dem Opfersystem zu löschen. Dieser Versuch der Angreifer scheiterte aber, so dass die SIT über nicht infizierte Sicherungskopien vor dem initialen Zugriff vom 18. Oktober 2023 verfügt und aus diesen die Nutzersysteme wiederherstellen kann.
Ransomware ohne Persistenz und nur Teilverschlüsselung
Beim Lesen des Forensik-Berichts sind mir noch einige Sachen aufgefallen, die teilweise ein Glücksfall für die SIT waren. So ist es den Akira-Angreifern nicht gelungen, abseits der Domain intra.lan auf andere in den Rechenzentren eingerichtete Domänen überzuspringen.
Auch gibt der Bericht an, dass keine Beweise gefunden wurden, dass die Ransomware w.exe auf Pertinenz oder die Kommunikation mit Servern der Angreifer ausgelegt war. Die Ransomware wurde auf eine Anzahl Systeme kopiert und dort am 30. Oktober 2023 gestartet, um die befallenen Systeme sowie alle Dateien auf Netzwerkfreigaben nach einem Muster rekursiv über alle Ordner zu verschlüsseln. Die Symantec-Sicherheitslösung protokollierte diesen Vorgang zwar, war aber nicht in der Lage, den Vorgang zu stoppen. Eine Persistenz der Ransomware konnte von den Forensikern keine festgestellt bzw. nachgewiesen werden – der Angriff war wohl auf die reine Verschlüsselung der Systeme ausgelegt.
Von den 770 Servern und 4176 Clients der Domäne intra.lan wurden lediglich 961 Systeme mit einer Ransomware-Notiz akira_readme.txt gefunden. Eine Verteilung der Ransomware per Gruppenrichtlinie scheint nicht stattgefunden zu haben, da sonst mehr Systeme befallen gewesen sein müssten. Die verschlüsselten Systeme dienten aber der Verwaltung und Bereitstellung der Dienste und Fachverfahren in den Kommunen der Kunden, so dass es bereits vor dem Abschalten der Dienste und Trennung vom Internet zu Ausfällen kam.
Im Bericht findet sich zudem die Information, dass die Ransomware eigene Log-Dateien führte und Dateien nur teilweise verschlüsselte. Dadurch konnten Inhalte von Log-Dateien rekonstruiert werden.
Angriff durch Menschen bemerkt
Der Hinweis in den öffentlichen Verlautbarungen, dass der Angriff am 30. Oktober 2023 erfolgte und sofort nach Erkennen gestoppt wurde, ist nicht so ganz richtig – und im wesentlichen den von der Presse verlangten Vereinfachungen geschuldet. Dass die Angreifer bereits seit dem 18. Oktober 2023 im Netzwerk unterwegs waren, hatte ich oben erwähnt.
Mir wurde von einer ungenannt bleiben wollenden Quelle bereits zeitnah im November 2023 berichtet, dass die Ransomware-Infektion am 30. Oktober 2023 erst gegen 2:00 Uhr auffiel, als eine Polizeiabfrage scheiterte, weil nichts mehr beim entsprechenden IT-Dienst ging. Darauf hin wurden die Verantwortlichen der SIT informiert und sämtliche Server gegen 6:30 Uhr heruntergefahren, sowie die Verbindungen ins Internet und zu den Kunden in den Kommunen gekappt. Ab diesem Zeitpunkt standen keine Dienste und Fachverfahren der SIT mehr für die Kunden zur Verfügung. Diese Zeitangaben finde ich auch so im Forensik-Bericht, was die Zusatzinformationen meiner Quelle nachträglich bestätigt.
Der Untersuchungsbericht weist für den 30. Oktober 2023 um 1:35 Uhr das Ende der "Symantec-Encryption-Meldungen" au. Ich vermute, dass zu diesem Zeitpunkt die erreichbaren Dateien bereits verschlüsselt waren. Es waren also Menschen, die den Angriff wegen fehlender Funktionalität bemerkten, und keine Sicherheits-/Überwachungslösung.
Keine Zahlungen und Neustart der SIT
Aus dem Bericht geht hervor, dass die Akira-Ransomware-Gruppe in allen Ordnern mit verschlüsselten Daten Textdateien mit der Aufforderung zur Kontaktaufnahme per Tor, zwecks Verhandlungen über eine Lösegeldzahlung, hinterlassen hat. Da die Südwestfalen IT aber über Backups verfügte, die nicht infiziert waren, fand keine Kontaktaufnahme mit Akira statt. Über die Höhe der Lösegeldforderung gibt es daher naturgemäß keine Angaben.
Seit dem 30. Oktober 2023 läuft die Analyse des Angriffs und parallel dazu erfolgte der Neuaufbau der Systeme. Erste Fachverfahren stehen für die Kunden in den Kommunen wieder zur Verfügung. Beim Neuaufbau werden die Vorschläge der zugezogenen Analysefirma zur besseren Absicherung der IT-Infrastruktur mit berücksichtigt.
Abschließendes Fazit: Bei der Aufarbeitung des Cybervorfall offenbarten sich auch gravierende Schwachstellen in der Infrastruktur des kommunalen IT-Dienstleisters Südwestfalen IT, die diesen Angriff überhaupt erst ermöglichten. Ein neuer Geschäftsführer soll ab dem 1. Februar 2024 die Aufarbeitung des Angriffs sowie den Aufbau einer neuen IT-Infrastruktur vorantreiben. Unter dem Strich ist den Betroffenen zwar ein großer Schaden entstanden. Aber die Opfer hatten Glück im Unglück, es hätte schlimmer kommen können. Und der Umstand, dass der Forensik-Bericht offen gelegt wurde, zeigt den Willen zur Transparenz und ermöglicht Dritten Lehren aus diesem Vorfall zu ziehen.
Ergänzung: Eine Zusammenfassung der Erkenntnisse habe ich auch bei Golem im Beitrag Vertraulicher Forensik-Bericht offenbart viele Versäumnisse veröffentlicht.
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
Hausaufgaben nicht gemacht und fehlendes Knowhow war auch hier mal wieder die Ursache des Unheils. Mit Schlangenöl drübergießen ist eben genau gar nichts erreicht. Und Cisco sowie das tödliche Trio einzusetzen zeugt auch nicht gerade von profunder Kenntnis aktueller security Themen. Cisco und Microsoft, zwei Unternehmen die mit Kompetenz prahlen, aber bei Security nahezu vollständig versagen. Mein Mitleid hält sich in Grenzen. Die öffentliche Kommunikation zum Vorfall war weitgehend erstunken und erlogen. Vertrauen? Nein. Mißtrauen? Sehr hoch bis maximal.
Das "Schlangenöl" hätte vermutlich geholfen wenn es nicht nur protokolliert hätte.
Defender for Endpoint hätte auch geholfen das dieser lokal vermutlich nicht abschaltbar wäre "Tamper-Protection".
und selbst wenn es abschaltbar war.
unter Linux gibt's Scripte die nachprüfen, ob ein Dienst noch läuft. Wenn nicht gibt's ne Email und er wird neu gestartet.
Das ist natürlich bei Windiws sehr schwer zu implementieren, weil nicht jedem Admin jederzeit klar ist, wann welche Dienste zu laufen haben.
Er kommt da teilweise nur mit Reverseengineering weiter, weil MS halt nicht alles dokumentiert.
wenn es backups gibt.. warum dauert das alles so lange?
wie hoch ist wohl die schadenssumme.. 100 Millionen?
Es reicht ja nicht, dass Backup einzuspielen. Erst ist es erforderlich, sicherzustellen, dass die Backups nicht infiziert sind. Dann ist zu analysieren, welche Systeme infiziert waren. Dann sind die neuen Systeme in einer sicheren Konstellation aufgesetzt werden. Das ist nicht binnen einer Woche möglich.
Backups zurückspielen ist alleine keine Lösung!
Denn dann hat man alle Sicherheitslücken genauso wieder offen wie vor dem Angriff.
Daher ist die richtige Reihenfolge Analysieren, Lücken schließen, Härtung der Systeme, ALLE Passwörter ändern (denn die alten sind in den Händen der Hacker) etc. und ganz am Ende kommt das Zurückspielen der Backups.
Das ist ja richtig… aber wofür mache ich dann Backups?
Entweder versuche ich Lücken zu finden und zu schließen oder ich setze das System neu auf (mit professioneller Unterstützung) und stelle die Daten, Datenbanken etc. aus dem Backup wieder her.. oder muss ich jetzt eine Lücke in einer Datenbank suchen? Das darf doch nicht so lange dauern..
Die reinen Daten (ohne das Betriebssystem) sind das wichtigste. Diese aus der Sicherung wiederherstellen, rettet das Firmenleben. Mit einem frischen, gehärteten System ohne Anwendungsdaten kannst du nichts anfangen. Die Ransomewaregruppen machen sich nicht die Arbeit, ihre Software in Datenbanken oder Exceltabellen zu verstecken, um nach dem Restore wieder präsent zu sein. Reinkommen, Systeme verschlüsseln, ggf. Daten abziehen. Sieht man sich abgezogene Daten von Unternehmen an, merkt man recht schnell, das niemand in der Ransomeware die Kronjuwelen sucht, kennzeichnet und kategorisiert. Ein paar Beispiele mit wichtigen Daten auf die Startseite, das Beiwerk des Rests mit dazu. Qualitätssicherung findet hier keine statt.
Ich weiß zwar nicht, was die SIT mit "Fachanwendungen" meint, aber ich stelle es mir so vor, daß auf jeweils einem dieser virtuellen Server ein Programmpaket von einem spezialisierten Anbieter läuft, das sowohl die eigentliche Programmlogik, möglicherweise einen SQL-Server und lokal abgelegte Daten umfaßt, ohne daß man das trennen könnte.
So ist es zumindest bei den "Fachanwendungen" die wir betreiben, etwa das (verpflichtende) Tool, welches die aktuellen Sanktionslisten der Bundesregierungen mit den Lieferadressen vergleicht oder die Anbindung an die Paketdienste (wie z.B. UPS WorldShip) für den Versand.
War teilweise den SIT-Meldungen zu entnehmen, z.B. Fachanwendung für Standesämter, oder Steuereinzug, oder Melderegister etc.
Das habe ich soweit verstanden.
Ich meinte eher die Art und Weise, wie die Daten abgelegt werden.
Um noch einmal auf mein Beispiel mit der Terroristen-Prüfung zurückzukommen:
Das läuft so: Ich kaufe bei einem spezialisierten Anbieter für solche Software (Ich nenne jetzt keinen Namen, der tut nichts zur Sache, aber vermutlich nehmen sich die Mitbewerber da alle nicht viel) ein entsprechendes Softwarepaket.
Dieser Anbieter kommt dann vorbei (heutzutage gerne auch mal virtuell), bekommt "seinen" nach Absprache vorbereiteten Server mit SQL-Server übergeben, installiert diese Software und lizenziert sie dann auch – etwa nach Anzahl Abfragen.
Schnittstelle ist ebenfalls definiert: Ich schicke die aktuellen Lieferadressen des Tages 'rein und bekomme eine Information, dass der entsprechende Kunde X am Tag Y zum Zeitpunkt Z nicht auf der Sanktionsliste stand und damit beliefert werden darf.
Der Server selbst ist für mich aber ab diesem Tag eine Black Box. Die SQL-Datenbank ist verschlüsselt (ich als kleiner Lieferant darf die Adreßdatenbank natürlich nicht sehen und bekomme nur im Ernstfall gesagt, ob ich einen "Treffer" gelandet habe.)
Natürlich muß ich alle Ergebnisse archivieren (am liebsten 10 Jahre, den Zirkus gibt es nur noch nicht so lange), damit ich – sollte ein Paket z.B. in Rußland auftauchen – nachweisen kann daß ich es etwa vor drei Jahren (und damit vor dem Krieg) dort hin geschickt habe.
Zudem wird meinem Geschäftsführer (und dem Exportkontrollbeauftragten, aber eben nicht nur) mit einem Gesetzestext vor der Nase herumgewedelt, der ihm nicht nur Monate, sondern Jahre Gefängnis androht, falls doch mal der Falsche beliefert wird.
Was mache ich dann mit einem solchen Server?
Wie gesagt er ist für mich eine Black Box, ich kann in nur als Ganzes im Veeam sichern und wiederherstellen.
Die Daten extrahieren kann und darf ich nicht (ich kann nur hoffen, daß der Softwareanbieter es kann), nach einem solchen Einbruch wieder anlaufen lassen aber auch nicht.
Also bitte ich den Anbieter (natürlich gegen horrende Tagessätze) die Software neu zu installieren und die letzten Daten zu übertragen.
Falls die oben beschriebenen hunderte Verfahren ähnlich gestrickt sind und allein die Standesamtsverwaltung mehrere Tage mit einem Externen braucht (hoffentlich kann man wenigstens die Ehe- und Scheidungsurkunden retten) kann ich mir schon vorstellen, warum der Wiederanlauf der SIT so lange braucht.
Ist das eigentlich so schwer zu verstehen? Es geht hier in bem Beitrag von G.B. um die Aufarbeitung eines Cyber-Angriffs auf ein IT-Systemhaus im KOMMUNALEN Umfeld. Da gibt es nichts mit Terroristenprüfung und Außenhandelsembargo oder dem ganzen Zinnober, den du da aufführst. Oder hast Du schonmal bei einer Kommune einen Server oder Software gekauft? Du als Privater Anbieter von derartigen Sachen hast die Probleme, eine Kommune egal welcher Größe hat die NICHT.
Und es gibt nicht "die Standesamtsverwaltung", die Daten eines jeden Standesamtes im Einzugsgebiet der SIT liegen auf einem eigenen Server. Und da gibt es die 8.000 Seelen Gemeinde ebenso wie die 100.000 Einwohner umfassende Großstadt. Und da es Standesämter ab 1874 gab, kannst Du Dir ungefähr vorstellen, welches Datenvolumen da vorhanden sein muß, wenn ein Großteil dieser Daten bereits digital aufbereitet wurde. Da sind mehrere Tage für die Überprüfung und ggfls. Restauration der Daten ein Klacks.
Viel mehr Zeit geht da bei der Überprüfung und ggfls. Restauration der Daten aus dem Bereich der Kasse drauf. Wenn der Buchungssatz zwar besteht, aber der zugehörige Eintrag in der Protokolldatenbank nicht da ist, weil zerstört, überschrieben oder gelöscht, dann nutzt der einzelne Buchungssatz auch nichts. Der muß dann manuell anhand von vielleicht vorhandenen Papierunterlagen nacherfaßt werden, oder bekommt den Eintrag "Original nicht mehr vorhanden, Cyber-Angriff vom 30.10.2023".
Also bitte mal beim Thema bleiben und nicht von eigenen Problemen reden, die hier überhaupt nicht zum Tragen kommen.
Moment mal, Ich wollte mich ja gar nicht über die Exportkontrolle ausk*tzen, (dafür ist das hier ohnehin der falsche Ort), sondern nur an einem mir bekannten Beispiel beschreiben, wie solche Software arbeitet.
In der "Preisklasse" habe ich als Mittelständler etwa 20 VMs, davon ca. 10 die ich gesetzlich haben muß (z.B. Zoll, Intrastat, Verpackung und verschiedene Sachen im Personalbereich) und ca. 10, die ich haben will (beispielsweise direkte Anbindung an Paketdienstleister wie UPS, die mir die Tracking-Nummern generieren, das Etikett mit QR-Code ausdrucken und die Sendungsinformationen gleich bei UPS in die Datenbank schießen).
Codequalität oft leider sehr bescheiden (auf Niveau eines Elster von vor 10 Jahren, riesige Java-Orgien), so daß ich sie natürlich isolieren muß und nicht einfach in die Warenwirtschaft integrieren kann.
Dank Virtualisierung ist so eine VM schnell ausgerollt, gesized und dank MS-Datacenter auch durchlizensiert.
Trotzdem kostet schon der Regelbetrieb Aufwand (CPU, RAM, Netz und natürlich alles ums Backup und Monitoring herum), in einem Einbruchsfall sind sie aber eben gesondert behandlungsbedürftig was Forensik und spätere Wiederherstellung betrifft.
Wenn die oben mehrfach beispielhaft zitierte Standesamtsverwaltung ähnlich aufgebaut ist (und vielleicht noch für jede Gemeinde getrennt ausgerollt wird) kann ich mir schon vorstellen, wo die ca. 900 Server herkommen und warum die Wiederinbetriebnahme so lange dauert.
Wenn meine bruchstückhaften Informationen aus der Leserschaft stimmen, sind die "Fachverfahren" a la Standesamtsverwaltung noch grauseliger – vor Jahren teilweise irgendwelche Coldfusion basierten WebApps sowie Schnittstellen zu zahlreichen internen Datenbanken und Systemen.
@Fritz: Zu den Interna liegen mir keine Informationen vor.
@Fritz:
Es ist aber vollkommen unerheblich, wie diese (Deine) Software arbeitet, weil es diese Software im kommunalen Umfeld einfach NICHT gibt. Punkt! Und es gibt auch nichts Vergleichbares dazu.
Bleiben wir beim Standesamt. Da gibt es eine Anwendungssoftware und den Datenbestand dazu. Das bedeutet, daß es eine Instanz "Server" für die Anwendung und eine Instanz "Server" für die Daten gibt. Inwieweit diese Instanzen jetzt jede für sich auf einem "Blech" laufen, oder ob es mehrere "Instanzen" als VMs auf einem "Blech" sind, ist auch erstmal egal. Und das gilt durch die Bank weg auch für fast alle Anwendungen, wie Einwohnerwesen, Kassenwesen, Sozialwesen, und, und und.
Oder machen wir ein Beispiel, bei dem Du näher dran bist. Dein Gewebesteuerbescheid wird zwar mit dem Zahlenwerk (Server-Instanz "Kasse") und den Adreßdaten (Server-Instanz "Einwohnerdaten") von Deiner Kommune erstellt, der Ausdruck geht dann aber als Auftrag an den für Deine Kommune zuständigen IT-Dienstleister. Ob der das jetzt in seinem Operating drucken läßt und die Briefe gesammelt zur Post gibt, oder ob die Daten elektronisch zum nächsten Postverteilzentrum geschickt, dort ausgedruckt, kuvertiert und verschickt werden, ist von It-Dienstleister zu IT-Dienstleister verscheiden. Und ja, dieser "Service" wird der Kommune in Rechnung gestellt und die muß diese Kosten wieder hereinholen. Wie, kannst Du Dir sicher vorstellen.
@ Günter Born:
Im Bereich "Standesamt" gibt es zwei große Hersteller in Deutschland, die eine entsprechende Anwendung im Portofolio haben. Das ist zum einen die PTC Gruppe mit ElVis und der Verlag für Standesamtswesen mit AutiSta. Im Bereich der SIT Hemer kommt seit Jahren AutiSta zum Einsatz, eine C/S-Lösung, die nicht auf "Coldfusion basierten WebApps" basiert.
dann hast du ein System, von dem du weißt, das es angegriffen wurde und kaputt ist. das schaltest du so nie wieder ein, denn es ist dann nur eine Frage von kurzer Zeit, bis du wieder dein Backup einspielst …
du musst erst Mal alles ändern, Infrastruktur, Administration etc und dann reden wir über das zurückholen der Daten, Scheibchenweise nach Überprüfung
Ja, wie schon vermutet grobe Fehler im AD gemacht:
Logs nicht groß genug, Domänen-Admin Account nicht deaktiviert, Passwort im Klartext in einem Gruppenrichtlinienobjekt abgelegt, VPN nicht mit 2FA abgesichert, Schlangenöl sicher nicht richtig konfiguriert, etc.
Die Systeme waren sicherlich auch sonst nicht gehärtet.
Im Grunde war die Ursache ein Totalversagen der Admins.
es war sicherlich nicht Klartext, sondern das "cpassword" Attribut im XML der GPP, geschlossen mit: MS15-025
dummerweise hat Microsoft es so geschlossen, das das Feld in der UI auch nicht mehr editiert werden kann. man muss das AES verschlüsselte cpassword per Hand aus dem XML löschen.
AES verschlüsselt? wir konnte das gehackt werden?
… weil Schlüssel und Schloss im MS GPREF Pdf veröffentlicht sind, thank God EU Import Richtlinie.
Ich frage mich wie jemand es für eine gute Idee halten konnte
– Das Domain-Admin Kennwort in einer GPP einzutragen
– Es über fast 10 Jahre nicht zu ändern
Ich betreibe die Systeme nicht, ich bin nur Kunde. Aber auf so eine blöde Idee wäre ich nicht gekommen.
Oder ziehe ich da falsche Schlüsse aus dem Bericht?
gelebte Praxis 2008-2016:
ein dient läuft mit einem Konto, kann der Admin sein.
du möchtest das Kennwort auf x Systemen ändern. das ging per "GPP Dienste" sehr gut, den das Kennwort ist AES verschlüsselt im xml, aka save
das es public im pdf war, kam erst 2013 in die Öffentlichkeit, davor galt es als sichere Methode Dienstkennworte zu ändern, da du im Gegensatz zu einem script kein Klartext Kennwort, nicht Mal über das Netzwerk, überträgt
Moin,
schau Dir nur mal die Personal-Fluktuation bei der SIT an und was alles bei Nununu so aufschlägt. Und jetzt stell Dir den oder die Admin(s) vor, die für die Systeme zuständig sind, weil sie die entweder aufgesetzt oder übernommen haben. Glaubst Du, bei dem was über den Flurfunk so nach draußen gelangt ist über das Betriebsklima, da hätte sich noch irgendein Admin die Mühe gemacht, seine Änderungen zu protokollieren oder den Nachfolger einzuarbeiten?
Nur mal als "Beispiel aus dem Leben": Da kommt ein junger Mitarbeiter der SIT, seines Zeichen Administrator für Windows-Domänen mit den entsprechen MSCE-Zertifikaten, in die Kommune und man kommt so ins Gespräch. Wies denn so läuft und Zufriedenheit und Kollegen und so weiter. Da erzählt der SIT-Mitarbeiter, daß die SIT zwar eine Stelle als Windows-Admin ausgeschrieben und er sich darauf beworben hat, und er auch so eingestellt worden ist. Nun soll er aber Linux-Systeme administrieren! Er ist jetzt mit einem Bein schon wieder auf dem Absprung, weil er das nicht mitmachen will und kann.
Soviel zu dem Thema: Paßwort in eine GPP eintragen und 10 Jahre nicht ändern.
Und mal anders herum gefragt: Würdest Du als Domänen-Admin, der eine bestehende Domäne übernommen hat, aus dem Stand wissen, in welchen Gruppen-Richtlinien welche Informationen abgelegt werden oder sein könnten? Und wenn Du das könntest und wolltest den Eintrag dann ändern, aber, wie oben geschrieben, der Eintrag ohne Änderungen an anderer Stelle nicht änderbar ist, was würdest Du dann machen? Einen anderen Admin fragen und Dich als unfähig hinstellen lassen oder alles so lassen, wie es ist?
So ein Passwort zu finden wäre Aufgabe von DLP/DLD
Data leakage detection.
….
Zumal das ja wohl ein bekannter Bug war, den Microsoft verbockt hatte im dem es den privaten Schlüssel veröffentlicht hatte. (scheint MS ja gerne zu machen).
Allerdings verstehe ich da auch nicht das Vorgehen.
Immerhin gibt es Kerberos und SSO.. da muß man doch keine Passwörter durch die Gegend schieben.
ich habe gerade nicht die Zeit und Lust dir historisch das Produkt Desktop Standard Policymaker (2006 gekauft von MS, umbenannt in Group policy preferences) Nähe zu bringen.
aber, MS hat es in dem Fall nicht verbockt und vor allem hat das ändern eines Dienstkonto kennwort AUF einen Server, in der Dienste Liste nichts mit SSO zu tun.
du änderst das Kennwort im AD und danach AUF allen Servern, wo es benutzt wurde. jetzt bist du im Thema Deployment. GPP Dienste war eine gute Lösung zur Verteilung, bis es herauskam.
btw: seitens MS war dieser Weg nie empfohlen, da denen die Technik bekannt war, die sie gekauft haben.
Kurzform:
der Schlüssel ist hardcodiert in der DLL gewesen , als es noch ein Drittanbieter war mit wenigen Kunden war das ziemlich egal …
Langform, wen es interessiert, jetzt habe ich Zeit …
Korrektur: Es war MS14-025, ich bin mit den Jahren durcheinandergekommen
https://learn.microsoft.com/de-de/security-updates/securitybulletins/2014/ms14-025
Anforderung: Verteilen / Deployment eines verschlüsselten (!) Passworts an ein Ziel
Teilnehmer: 1- x-Tausend
Voraussetzung: Schlüssel und vor Allem Entschlüsselungsschlüssel müssen jedem Teilnehmer bekannt sein.
Challenge: Woher nimmt man oder kriegt man einen Schlüssel, den jeder kennt?
a) Man gibt ihn bei der Installation mit, Massendeployment per MSI
Wait … dann steht der da im Klartext in der Install Commandline.
Wie übergibt man ein Verschlüsseltes Kennwort zur Installationzeit?
Gar nicht. Du drehst dich im Kreis. Du hast keinen gemeinsamen general Schlüssel
Der pro Kunde dynamisch generierte Schlüssel entfällt also.
b) Man kann den "eigenen" Schlüssel bei Erst Aufruf am Client eingeben.
Hahahaha, nein. Nicht bei mehr als 5 Computern. Desktopstandard hat Enterprise als Kunden adressiert.
c) PKI! Bähm! Yes!
Wait, das hat nicht jeder Kunde und die werden dir keine PKI adhoc installieren, nur weil
du ein geiles Gruppenrichtlinien Addon verteilen möchtest.
Du siehst alle Idee fallen aus, bis auf:
d) Der Schlüssel kommt hardcodiert in die DLL
Zack. Genau das ist passiert. Die Technik wurde behalten, als MS sie gekauft hat.
Jetzt kommt der richtig geile Scheiss:
Die EU sagt, wenn du eine Verschlüsselung von ausserhalb der EU in die EU exportieren möchtest,
dann musst du sie offen legen. Das ist für die meisten kein Problem, die Verweisen auf den AES Wikipedia
artikel und sagen der "Key" ist dynamisch vom Kunden und steht nur als Variable im Algorythmus.
Leider ist der Key der gppref.dll IN der DLL. Damit ist er Bestandteil der Verschlüsselung und muss offen gelegt werden.
:-D Geil, oder?
Wer Langeweile hat, der schaue ins PDF und suche nach "AES".
https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-gppref/232e3242-e88a-45b5-a02f-dede30917279
Seit 2013 gibt es ein Public Powershell Script, das den AES Key im cpassword Feld in Klartext zurückverwandelt.
Das PoSH Script macht genau das, was die DLL am Client macht, wenn sie das PAssword verwenden soll.
Sie entschlüsselt das Feld.
DLP/DLD .. in diesem Fall hätte Notepad++ gereicht, um alle cpassword Einträge in allen xml des sysvols/policies zu finden.
wenn man es weiß …
Bist Du des Teufels – dieses Windows ist doch per Passwort geschützt und was Du da machst, ist Daten ausspähen (Amtsgericht Jülich verurteilt Entdecker der Modern Solutions-Schwachstelle zu Geldstrafe (Jan. 2024)).
Aaaaaaaaaah. Ich habe nichts gemacht. Ich schwöre. Alles nur Hören, Sagen, weitersagen. ;-)
Mich würde ja interessieren wieso Sie sicher waren das Ihr Backup (und vor allen Dingen ab wann bzw. welches) nicht betroffen war. Haben Sie das aus den Logs geschlossen oder haben vor dem zurückspielen eine Prise Schlangenöl draufgeworfen? Meisten liest man ja das die Angreifer mehrere Tage/Wochen oder teilweise Monate im System sind und ggfls. Backdoors installieren bevor Sie anfangen zu verschlüsseln. Sicher nicht ganz einfach das im Sicherheitskonzept oder beim Restore zu berücksichtigen oder?
Stimmt.
Die haben zwar anhand der vorhandenen Logs festgestellt, das die ab 18.10.23 aktiv waren, aber die Logs reichen nur bis Anfang Oktober zurück.
Was davor war, wissen die schlicht nicht.
Auch da schon könnten sich die Akteure im System umgesehen haben.
Gewissheiten wird es nie geben – aber die Leute von der Forensik arbeiten mit Wahrscheinlichkeiten und plausiblen Annahmen (habe ich dem Bericht zwischen den Zeilen entnommen). Kann falsch sein, aber irgendwann muss jemand eine Entscheidung treffen.
Ich finde es auch bemerkenswert, das wir den Forensikbericht öffentlich lesen dürfen. Jeder Security Verantwortliche sollte den Bericht lesen und sich bei jeder Erkenntnis aus dem Vorfall fragen: Hätten meine Systeme dies erkannt ? Wären z. B. 190 Login Versuche bei uns alarmiert oder nur protokolliert worden ? Eine sehr gute Quelle, Dinge im eigenen System zu prüfen und ggf. nachzujustieren. Sollte jemand dabei sein, bei dem keiner in diesem Bericht erwähnten Thematiken zutreffen, hat er alles richtig gemacht. ;-)
Ich finde es nach wie vor irritierend, dass der Geschäftsführer seinen Hut genommen hat/nehmen musste. Die wahren Schuldigen erfreuen sich weiterhin der Beschäftigung?
Naja, wer weiß, ob die, die 2014 das Passwort in die Gruppenrichtlinien gepackt haben, noch im Unternehmen sind.
Und ob die Nachfolger davon gewusst haben.
Auf jeden Fall aber hätten sich neue Admins erst einmal einen groben Überblick über die Domäne und deren Sicherheit verschaffen müssen.
Und am Ball bleiben muß man eh, denn Sicherheitsrichtlinien können sich ändern, mit Patches o.Ä. können neue Möglichkeiten bzgl. Sicherheitseinstellungen hinzu kommen, etc.
Rechtliche Verantwortung für IT- und Datensicherheit obliegt dem Geschäftsführer. Laden nicht im Griff? Abdanken. Völlig richtige Entscheidung.
Moin,
schau Dir mal die Daten der SIT GmbH auf North Data an,
https://www.northdata.de/SIT+GmbH,+Hemer/Amtsgericht+Iserlohn+HRB+2686
wer seit 2003 da alles auf dem "Chefsessel" saß. Und soweit ich das mitbekommen habe, ist der letzte GF auf eigenen Wunsch von seinem
Posten entbunden worden. Und ich denke mal, mehr aus "Schnauze voll" als "Laden nicht im Griff".
Die Griffigkeit wurde schon lange vorher auf dem Weg dahin verloren.
Vielleicht hat der das immer schon gesehen und konnte es gegenüber den Eigentümern nicht durchsetzen und hat die Brocken endlich hingeschmissen?
Oder er hat versucht zu vertuschen?
Es ist natürlich in so einer Situation nicht der optimale Zeitpunkt für einen Wechsel.
Woher haben die denn so schnell einen neuen GF bekommen, der diese sehr unangenehme Aufgabe übernommen hat, da gründlich aufzuräumen?
Es schimmert ja schon etwas laissez-fair durch, wie 14 Jahre kein Passwort zu ändern oder zu kleine Log Files (die ja täglich gefilzt werden müssten…)
Ich hab ja schon zu dem "neuen" GF was geschrieben. Und wenn ich mir die Reihe der GF so anschaue, dann hat das unter einer kommunalen Führung recht gut funktioniert (70er jahre bis ca. 2000). Danach hat der GF gewechselt und es kam jemand aus der freien Wirtschaft (Materna) ans Ruder. Der hat zunächst dem Kommunalbetrieb einen neuen Namen verpaßt (citkomm) und dann ab 2004 angefangen, die SIT GmbH Hemer umzubauen und aufzuteilen in die citkomm services GmbH (ehemaliger Kommunalbetrieb) und die citkomm assets GmbH (Personalpool der citkomm services GmbH). Damit begann der eigentliche Abstieg der SIT GmbH Hemer. Die Mitarbeiter der citkomm wurden zwangsweise in die …assets GmbH "migriert" oder durften das Haus verlassen. Die Abkehr von Eigenentwicklungen hin zu Lösungen vom Markt hat dann auch dazu geführt, daß ein Großteil der Programmierer nicht mehr benötigt wurde. Nur dumm, daß knapp eine Olympiade später die Erkenntnis reifte, daß die Entscheidung nicht so toll war und nun mit Macht wieder Programmierer gesucht wurden. Doch die, die die Kenne der alten Programme hatten, waren mittlerweile in anderen Bereichen tätig. Die Kirsche auf dem Sahnehäubchen war dann noch das Eingeständnis, daß man seitens der SIT ein Programm, das von fast allen Kommunen genutzt wurde, nicht weiter anbieten kann, da der zuständige Programmierer in Rente ging und es keinen Nachfolger gab, der die Anwendung hätte weiter pflegen können.
2022 hat sich dann der aktuell GF verabscheidet, um sich selbständig zu machen und die Geschäfte an seinen Stellvertreter übergeben. Der war aber offensichtlich von den Aufgaben überfordert, sodaß der Posten des GF auf die GFin der …assets GmbH überging. Aber auch der war kein Glück beschieden, da sie sich zu Höherem berufen fühlte und eine Position in der Kommunalverwaltung ihres Heimatortes anstrebte. Die Bewerbung fand dann unter ferner liefen statt. Tja und so hat man kurzer Hand erneut einen der Stellvertreter der … services GmbH auf den nun verwaisten Sessel gehieft. Der hat aber nach kurzer Zeit das Handtuch geworfen und ist auf eigenen Wunsch vom GF-Posten zurückgetreten.
Wie/wo kann man in den GPOs ein Domänenadmin-Kennwort speichern? Und zu welchem Zweck?
Wie:
https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-gppref/2c15cbf0-f086-4c74-8b70-1f2fa45dd4be
Warum:
Vielleicht sollte ein Dienst oder ein geplanter Task nicht mit den Rechten des Systems sondern mit benannten Rechten laufen. Ein Grund wurde nicht genannt.
group policy preferences: services, local user and groups, tasks
zweck? Viele
-Änderung des lokalen Admin Kennworts 8 Jahre bevor es Laps gab
– erstellung eines lokalen Benutzers mit Kennwort
– task Benutzer Kennwort hinterlegen
– Dienstkonto Kennwort ändern
jede der Stellen ist jetzt ausgegraut, durch MS16-025, also auch schon seit fast 8 Jahren
Was ich nicht nachvollziehen kann ist, das zum Verschlüsseln WinRAR verwendet werden sollte und dieses nicht mitgebracht worden sein soll.
WinRAR ist wahrlich keine Software die man überall voraussetzen kann, schon aus Lizenz gründen.
Natürlich erhöht der Einsatz mitgebrachte Software das Entdeckungsrisiko,weil diese Version evtl. dem Intrusion detection als PUA bekannt ist, aber zum komprimieren bringt Windows inzwischen ja auch eigene Tools mit.
War der nicht-Start evtl. das Werk der Intrusion-Detection/Prävention? Somit also kein Zufall/Glück?
Was ich auch nicht nachvollziehen kann ist, das ein lokaler Anbieter Verbindungen aus dem Ausland zulässt, resp. nicht nur due die IP-Adressen der Kunden zugelassen hat.
Natürlich besteht auch hier das Problem wie bei MFA,das die Clients korrumpiert worden sein können, aber es gilt auch hier St.Florians-Prinzip.
Die Angreifer werden immer den einfacheren Weg gehen. Und wenn ihre IP garnicht vom VPN angenommen werden, warum sollten es nicht lieber woanders probieren.
Natürlich kann man honeypots und boobytraps aufbauen um von den eigentlichen Zielen abzulenken.
Aber da den Angreifern erstmal egal ist, wo sie rein kommen, zieht man unnötige Aufmerksamkeit auf sich.
Also das ausprobieren von Passwörtern kann man nicht als gezielten Angriff interpretieren.
Dazu gibt's viel zu viele gecracke Systeme die es stumpf überall zu probieren. Mach mal Port 22 (SSH) auf. Du hast in kürzester Zeit einen "Angriff" drauf.
Den Scripten ist es völlig wurscht. Sie kommen von verschiedenen IP.
Das übliche Vorgehen um das Logfile sauber zu halten ist, sehr nicht auf Port 22 zulegen, sondern irgendwie woanders. Das hat man ja selbst im Griff.
Natürlich sollte man Portscans verhindern, in dem man Port/Html-knocking einrichtet. D.h. wer an das VPN will, muss von der Homepage erstmal bestimme Seiten abrufen. Erst damit wird das Routing für diese IP freigegeben. Das bedeutet natürlich Mehrarbeit für Admins. Und 100% sicher ist es auch nicht, wenn der Home Office Client korrumpiert ist…
Dann bleibt noch die berühmte Schaktuhr, die Zugriffe außerhalb der üblichen Arbeitszeiten verhindert, und so die Angriffsfläche merklich reduziert. ja, klar. Es ist für einen internationalen Konzern schwierig zu implementieren…
irgendwas ist immer. Aber bei einem solchen lokalen Anbieter? Auch hier macht es echt Arbeit, verglichen zum TagundNachtderoffenen Türen.
Aber es ist immer das Dreieck aus Kosten-Komfort-Sicherheit.
Jedenfalls ist es ein gutes Zeichen, das die SIT den Einbruch genau beschreibt.
Vermutlich werden viele die das gelesen haben, die Loggiles vergrößert haben und sind alle VPNs durchgangen, ob sie MFA haben.
Moin,
"WinRAR ist wahrlich keine Software die man überall voraussetzen kann, schon aus Lizenz gründen."
Stimmt nur bedingt, da WinRR als "freie" Version zwar in der Nutzung auf 40 Tage begrenzt ist, aber eine Weiternutzung über diesen Zeitraum hinaus problemlos möglich ist. Es erscheint nach den 40 Tagen allerdings ein Nag-Screen, der auf den Ablauf der Testversion hinweist. Nachdem der Hinweis jedoch "abgenickt" wurde, startet das Programm ohne weitere Einschränkung. Der Hersteller hofft auf die Ehrleichkeit der Nutzer.
"Was ich auch nicht nachvollziehen kann ist, das ein lokaler Anbieter Verbindungen aus dem Ausland zulässt, resp. nicht nur die die IP-Adressen der Kunden zugelassen hat."
Was über diese "amerikanischen IP-Adressen" bekannt ist, so liegen die alle in Netzen, die mit "10" beginnen, sind also "private" Class-A Netze. Laut dem Cyber-Bericht wurde vor dem Angriff ein Netzwerk-Scan auf die IP-Adressen innerhalb der jeweiligen Domänen-Server gestartet. Wenn nun der Scan auf einzelne IPs einer Domäne keine Antwort liefert, hat ein Angreifer schon einmal einen Pool von IP-Adressen, die zu einer gültigen Anmeldung über den VPN-Zugang führen, denn die IP-Adressen der Kunden-Domänen im Bereich der SIT sind ja zugelassen. Eigentlich sind IP-Adressen aus einem Class-A Netz gemäß IANA-Konventionen nicht routbar, aber IP-Spoofing sollte da den Angreifern in die Hände spielen.
Mir liegt eine (unverifizierte) Information vor (habe ich in den Beiträgen nicht thematisiert, ergänze es aber mal hier), dass VPN-Adressen der kommunalen Kunden der SIT "vor einiger Zeit" wohl für den Adresskreis 10.xx.xx.xx konfiguriert war, und ein Adresskreis 172.xx.xx.xx für VPN-Verbindungen aus dem Homeoffice eingerichtet war. Ob es beim Angriff noch so war, ist offen.
Das ist in dem Incident-Report eigentlich sehr gut visualisiert, siehe z.B. Seite 40:
103.xx.xx.xx – externe IP für VPN genutzt (USA)
107.xx.xx.xx – externe IP für VPN genutzt (Niederlande)
und
10.xx,xx,xx – intern vergebene IP nach VPN-Zugriff, nur relevant von xx – xx Uhr
oder Seite 15:
Erfolgreicher RDP-Login
Source: 10.xx.xx.xx
Target: 172.xx.xx.xx
Target-Hostname xxxxxx,intra.lan
10er IPs, die als "amerikanisch" betitelt werden sehe ich da keine.
"Unternehmen sollten sich bewusst sein, dass die Wahrscheinlichkeit für den Eintritt eines Sicherheitsvorfalls in den nächsten 24 Monaten bei nahezu hundert Prozent liegt."
Dr.-Ing. Stefan Rummenhöller, Geschäftsführer r-tec
genau..
30.10. bis 31.12… die haben da 2 Monate Forensik gemacht. Ohne Worte..