Die Telekom und das CERT-Bayern haben Ende Februar 2024 eine Phishing-Kampagne des Angreifers TA577 beobachtet, die gezielt auf eine Outlook-Schwachstelle CVE-2024-21413 ausgerichtet ist. Über diese Schwachstelle, die im Februar 2024 geschlossen wurde, sollen gezielt NTLMv2-Hashes von angreifbaren Exchange-Systemen abgerufen werden. Ich greife das Ganze hier mal im Blog auf.
Anzeige
Ein Blog-Leser hat mich bereits am 28. Februar 2024 auf den Sachverhalt hingewiesen – ich komme erst jetzt dazu, das aufzugreifen. In einer Reihe an Tweets schreibt Telekom Security, dass man mit dem Bayern-CERT am 26. und 27. Februar 2024 Phishing-Kampagnen des Bedrohungsakteurs TA577 beobachtet habe.
Diesmal verbreitet der Akteur keine Schadsoftware, um Anmeldedaten/Hashes zu stehlen. Vielmehr wird in den Phishing-Mails offenbar versucht, NTLMv2-Handshakes auszuführen, um entsprechende NTLMv2-Hash zu erbeuten.
Die Opfer erhielten ein gezipptes HTML-Dokument, das über den enthaltenen "file://…"-Link eine Verbindung an den SMB-Server des Angreifers weiterleitete. Eine solche URL führt im Edge oder Chrome beim öffnen dazu, dass der Browser eine Verbindung zum Server des Angreifers herstellt, ohne eine Bestätigung zu verlangen! Dabei wird der NTLMv2-Hash übermittelt.
Verbindet sich das System des Opfers mit dem SMB-Server des Angreifers, wird eine NTLMv2 Challenge/Response-Authentifizierung durchgeführt. Wer den Handshake genauer untersucht, kann mehrere verdächtige Elemente darin erkennen.
Die Server-Challenge hat zum Beispiel immer den Wert "aaaaaaaaaaaaaaaa". Bei einem normalen Handshake sollte dieser Wert zufällig sein. Wenn der Angreifer beabsichtigt, das Kennwort aus der gehashten Antwort zu knacken, hilft die Festlegung eines festen Wertes erheblich, den Prozess zu beschleunigen, schreibt die Telekom hier. Außerdem sind die im Handshake gesendeten Computernamen immer zufällige Sequenzen von 8 ASCII-Zeichen, was darauf hindeutet, dass der Angreifer impacket smbserver verwendet, ein Pentesting-Tool, das üblicherweise verwendet wird, um NTLM-Hashes zu erhalten.
Derzeit ist nicht bekannt, was das eigentliche Ziel von TA577 bei diesem Angriff ist. Gestohlene NTLM-Hashes oder geknackte Passwörter könnten für verschiedene Folgeangriffe verwendet werden. Eine Verbindung zu CVE-2024-21410 (Exchange NTLM Relay Vuln) ist möglich. In der Zwischenzeit empfehlen die Telekom-Sicherheitsleute, ausgehende SMB-Verbindungen zum Internet in Unternehmensnetzwerken zu blockieren. Es ist zu erwarten, dass andere Bedrohungsakteure in naher Zukunft dieselbe Strategie für ihre Angriffe nutzen werden.
Beim Schreiben dieses Blog-Beitrags bin ich auf diesen frischen Artikel gestoßen, der sich auf eine Beobachtung von ProofPoint stüzt, die ebenfalls die Phishing-Welle zum 26./27. Februar 2024 beobachtet haben. ProofPoint hat die Kampagne samt den Details zum 4. März 2024 im Beitrag TA577's Unusual Attack Chain Leads to NTLM Data Theft dokumentiert.
Anzeige
Ausnutzung der Schwachstelle CVE-2024-21410
Ähnliche die Telekom vermute ich, dass TA577 die Schwachstelle CVE-2024-21410 über Outlook ausnutzen möchte. Ich hatte zum 15. Februar 2024 im Blog-Beitrag Microsoft Security Update Summary (13. Februar 2024) über die Microsoft Exchange Server Elevation of Privilege-Schwachstelle, CVEv3 Score 9.8, critical (kritisch) berichtet. Eine erfolgreiche Ausnutzung dieser Schwachstelle würde es einem Angreifer ermöglichen, einen New Technology LAN Manager Version 2 (NTLMv2) Hash gegen einen anfälligen Server weiterzuleiten.
NTLM-Hashes könnten in NTLM-Relay- oder Pass-the-Hash-Angriffen missbraucht werden, um die Position eines Angreifers in einer Organisation zu stärken. Laut Microsoft ist vor Exchange Server 2019 Cumulative Update 14 und früher standardmäßig kein Schutz für NTLM-Zugangsdaten-Relay aktiviert. Der Microsoft-Hinweis enthält einen Link zu einem Skript zur Aktivierung des Schutzes (es wird Extended Protection benötigt) und empfiehlt die Installation des neuesten kumulativen Updates, auch wenn das Skript zur Aktivierung des NTLM-Anmeldeinformations-Relay-Schutzes bereits ausgeführt wurde.
Im Blog-Beitrag Nachlese zu CU 14 für Exchange 2019 und Schwachstelle CVE-2024-21410 (Feb. 2024) finden sich einige Hinweise, was Administratoren zur Absicherung ihrer Exchange-Server tun müssen.
Ähnliche Artikel:
Microsoft Security Update Summary (13. Februar 2024)
Exchange Server Update CU 14 (13. Februar 2024)
Nachlese zu CU 14 für Exchange 2019 und Schwachstelle CVE-2024-21410 (Feb. 2024)
2015
Diese Angriffe zeigen, dass ein Patch-Management kein Luxus oder Adminspielzeug ist, sondern essentiell.
Der letzte Patchday ist drei Wochen her. In einer ordentlich verwalteten Umgebung gibt es heute kein Outlook mehr, welches über diese Sicherheitslücke anzugreifen ist. Wer Stand heute noch ein Office vor dem Stand Februar 2024 in seinem Netzwerk betreibt oder dies nicht mal weiß, dem würde ich dringend empfehlen Maßnahmen zur besseren Verwaltung von Sicherheitsupdates zu implementieren. Es wird nicht besser werden in der nächsten Zeit.
Naja, da bin ich ja froh, dass deine Kollegen keine 3 -4 Wochen Urlaub haben!
Und Herzlichen Glückwunsch, dass Du die Patche innerhalb kürzester Zeit testen konntest!
Leider bleibt zum 'testen' nur wenig Zeit:
Sobald die Patches öffentlich sind, können auch die bösen Buben 'testen'. Nur testen die auf was Anderes… Wenn die mit ihren Tests fertig sind und den Angriffsvektor extraiert haben, sollte ich mit dem Patchen fertig sein.
Bei mir läuft das so:
Am Patchtag lese ich fleissig verschiednee gewöhnlich gut informierte Quellen auf der Suche nach Problemen mit den Updates.
Am Tag danach patche ich eine kleine Testgruppe von produktiven Rechnern, deren Ausfall ich kompensieren kann.
Taucht da nix auf und in den informierten Quellen taucht auch nix auf, patche ich am dritten Tag alle Rechner.
Irgendwas ist immer, aber dicke Bugs sollte ich so rechtzeitig mitbekommen, bevor alles lahm liegt.
Gruß
Wir verwenden eine Testgruppe, welche die Updates als erstes erhält. Darin ist auch die IT vertreten, so dass wir zusammen mit anderen Infos wie aus diesem Blog recht schnell eine Info haben ob alles läuft und die Updates funktionieren.
Im Netzwerk verwenden wir WakeOnLAN, um Clients bei anstehenden Updates aus der Ferne zu starten. Die Abdeckung für WakeOnLAN wird immer besser, da wir bei neuen Clients speziell darauf achten. Sonst tut es auch ein Anruf bei einem Kollegen in der Nähe, welcher für uns einmal den Power-Button betätigt. Die meisten Clients sind eh täglich online und das Problem existiert wirklich nur bei längeren Abwesenheiten.
Patches werden wahlweise per MEM oder Third-Party Patch-Management ausgerollt. Hat ein Client Internet, so können wir diesen auch außerhalb der Firma zum patchen verpflichten.
Natürlich bleibt Arbeit bei der Nachkontrolle, wenn Patches z.B. auf einem Gerät nicht wollen. Mit der aktuellen Struktur ist es für uns machbar die Updates zeitnah zu verteilen. Third-Party Applikationen kommen ja zusätzlich immer außer der Reihe und müssen auch verteilt werden.
Von Hand ist das aber nicht mehr machbar, schon alleine, weil einem die Übersicht fehlt welche Anwendung eigentlich wo installiert ist. Entsprechend auch mein Kommentar, dass ein Patch-Management heute nicht mehr optional sein sollte. Zumindest nicht wenn man mehr als ein Dutzend Clients zu administrieren hat.
Sehe ich genauso!
Leider ist das bei vielen immer noch überbewertet bzw "es reicht ja, das wir eine Firewall haben" ..
Traurig aber wahr.
Es geht aber noch viel besser. Kenne da ´nen Abteilungsadmin. Etwa 20 Server, dreistellige Anzahl Clients. Arbeitet nur als Domänen-Admin. Lokale Admins auf den Clients haben den gleichen Namen und das identische Kennwort. Letzte Kennwortänderung war irgendwann zwischen 2006 und 2008. Updates und Windows-Firewall sind per GP deaktiviert. Gibt ja eine übergeordnete zentrale Firmenfirewall. Updates werden ca. alle 6 Monate installiert. Außerdem ist der Zustand so seit NT4 und ist noch nie etwas passiert. Auf so manchem Client läuft noch Office 2010. Andere Software ist ähnlich "neu".
Und nein, das ist kein Scherz.
Im Prinzip hast du Recht.
Aber:
Auch ungepatchte Outlook-Versionen sind sicher, wenn z.B. eine der folgenden Voraussetzungen erfüllt sind:
1. Port 445 (SMB) ist ausgehend in der Firewall geschlossen.
Mir fällt kein Grund ein, warum dieser Port ins Internet offen sein müsste.
2. EP ist auf dem Exchange aktiviert.
3. Es wird gar kein NTLM in der Domäne genutzt, sondern Kerberos.
Wo es kein NTLM gibt, können keine NTLM-Hashes abgegriffen werden.
Nichtsdestotrotz sollte man die Software aktuell halten.
Und hinzu kommt, das man die Anwender im Umgang mit Emails schulen muss.
Z.B.: Niemals Anhänge von unbekannten Absendern öffnen, niemals auf Links in Emails klicken, wie erkenne ich Phishingmails, etc. etc.
Wenn man sich einmal die ganzen Cybervorfälle der letzten Zeit anschaut, dann liegt die Ursache meist nicht in den ystemen selbst begründet, sondern die Ursachen sind meist:
– Fehlkonfigurationen von Servern, Firewalls, etc.
– mangelndes Patchmanagement
– mangelnde Härtung der Systeme
– Einsatz veralteter Komponenten (Software, Treiber, etc.)
– mangelnde Schulung der Anwender
– etc.
90% der erfolgreichen Cyberangriffe hätte man verhindern können, wenn die jeweiligen Admins ihren Job gemacht hätten!
Es geht doch nicht um Outlook, sondern Exchange. Man kann nicht einfach werktags ein neues CU einspielen, ohne dass mehrere Benutzer plötzlich Kennwortabfragen für ihr Postfach bekommen. Auch nicht mit Exchange-Cluster, selbst wenn man die CUs nacheinander aktualisiert.
Ich verlasse mich auf ESET Mail Security. Das aktualisiert die Erkennung-Routinen bei Bedarf bis zu 6x am Tag und blockt zuverlässig die Schwachstellen sobald sie bekannt sind.
Nicht ganz günstig, aber nicht mein Geld :)
Es geht hier nicht primär um Microsoft Exchange. Wie oben im Artikel geschrieben:
"Die Opfer erhielten ein gezipptes HTML-Dokument, das über den enthaltenen "file://…"-Link eine Verbindung an den SMB-Server des Angreifers weiterleitete."
Das Öffnen des Anhangs führt dazu, dass der Client einen externen Server per SMB anspricht und dabei wird dann der NTMLv2-Hash übertragen. Hier ist der Mail-Server erstmal nicht involviert.
Wie R.S. bereits schön aufgelistet hat, gibt es neben dem Office Patch für Outlook viele Wege die Ausnutzung der Lücke zu unterbinden:
1. Port 445 (SMB) ist ausgehend in der Firewall geschlossen.
2. EP ist auf dem Exchange aktiviert.
3. Es wird gar kein NTLM in der Domäne genutzt, sondern Kerberos.
Wo es kein NTLM gibt, können keine NTLM-Hashes abgegriffen werden.
Ja, unter Punkt 2 gibt es auch eine Einstellungsmöglichkeit, welche die Nutzung der erbeuteten NTMLv2-Hashes bei Exchange unterbindet. Das gilt dann aber nur für Exchange. Was ist mit anderen Diensten welche auch auf IIS basieren?
Auch ist EP kein neues Feature, sondern schon lange verfügbar. Ich meine das wurde 2022 für Exchange eingeführt. Wer das bei heute nicht realisiert hat, der hat einfach mal gepennt.
Mail-Security ist grundsätzlich gut, auch wir scannen Mails. Unsere Erfahrung zeigt aber auch, dass gerade neue Bedrohungen nicht unbedingt sofort als Virus/Malware erkannt werden. Mail Security ist ein legitimer Baustein, aber greift meiner Erfahrung nach als einige Maßnahme zu kurz.
Hier ähnlich wie bei Werner. Unterschied: trotz Testgruppe wird am 3. Tag nur die Hälfte der Rechner einer jeden Abteilung mit den Aktualisierungen versorgt. Läuft mächtig was schief, ist die andere Hälfte der Abteilung noch arbeitsfähig. Klappt das gut, wird der Rest der Maschinen an Tag 4 mit den Aktualisierungen versorgt.
Info:
Diese russische TA577 Spamwelle besteht aktuell noch immer. Bereits in 2023 ehielten wir eine erste E-Mail.
1. E-Mail am 14. April 2023, angeblich von Anna Kirilova, zip-datei angehängt (angeblich Rechnung)
Diese E-Mail wurde vom Netzwerk via mailjet.com versendet.
2. E-Mail am 01. März 2024, angeblich von Telekom Deutschland GmbH, zip-datei angehängt (angeblich Rechnung)
Diese E-Mail wurde vom Netzwerk via sendinblue.com (heute brevo.com) versendet.
3. E-Mail am 01. März 2024, angeblich von Telekom Deutschland GmbH, zip-datei angehängt (angeblich Rechnung)
Diese E-Mail wurde vom Netzwerk via sendinblue.com (heute brevo.com) mit Datumsangabe 30.11.2046 versendet.
4. E-Mail am 01. März 2024, angeblich von Telekom Deutschland GmbH, zip-datei angehängt (angeblich Rechnung)
Diese E-Mail wurde vom Netzwerk via sendinblue.com (heute brevo.com) noch einmal mit Datumsangabe 30.11.2046 versendet.
5. E-Mail am 04. März 2024, angeblich von Melanie Breitkopf, zip-datei angehängt (angeblich Rechnung)
Diese E-Mail wurde vom Netzwerk via mailjet.com versendet.
6. E-Mail am 05. März 2024, angeblich von ImPressa, zip-datei angehängt (angeblich Rechnung)
Diese E-Mail wurde vom Netzwerk via mailjet.com versendet.
7. E-Mail am 06. März 2024, angeblich von Ressource Peintures, zip-datei angehängt (angeblich Rechnung)
Diese E-Mail wurde vom Netzwerk via sendinblue.com (heute brevo.com) versendet.
Glaube dass vor allem für Netzwerke/Personen, die keine echte Gatewayfirewall besitzen, diese Lücke noch Fatal wird. Standard-Router blockieren keine ausgehenden SMB-Anfragen….
Hier sehr Interessante Analyse von Checkpoint, mit unschönen Ausblick….
https://research.checkpoint.com/2024/the-risks-of-the-monikerlink-bug-in-microsoft-outlook-and-the-big-picture/