EXCHANGE-HACK: WELCHE MASSNAHMEN UNTERNEHMEN JETZT ERGREIFEN MÜSSEN

Patchen, weitere Angriffe verhindern und Kompromittierungen finden – Firmen sollten gegen Hafnium gezielt und nach einem bestimmten Schema vorgehen.

Hafnium hält die IT-Welt weiter in Atem. Auch wenn die Out-of-Band bereitgestellten Patches von Microsoft für alle im Support befindlichen Versionen von Exchange und sogar für ältere Versionen zur Verfügung stehen, kommt dies für viele Systeme zu spät. Allein das niederländische DIVD CSIRT hat 46.000 Warnungen an Betreiber angreifbarer Instanzen verschickt. In den Telemetriedaten eines einzigen Security-Anbieters (ESET) finden sich bereits Hinweise auf mehr als 5.000 durch Webshells kompromittierte Systeme.

Was ist also in der aktuellen Lage zu tun? Im Folgenden sind die wichtigsten Praxistipps für die Hilfe zur Selbsthilfe zusammengestellt.

Betroffene Systeme

Laut den Hinweisen von Microsoft sind die folgenden Systeme betroffen:

• Exchange 2010 (nur Schwachstelle CVE-2021-26857)
• Exchange 2013
• Exchange 2016
• Exchange 2019

Alle diese Server sollten Unternehmen, sofern immer noch nicht erfolgt, sofort patchen.

Auch wenn sich Exchange 2003 oder 2007 nach heutigem Kenntnisstand nicht in der Liste wiederfinden – der Support dieser Systeme ist längst abgekündigt – sie weisen andere kritische Schwachstellen auf und sollten deshalb dringend auf eine aktuelle Version aktualisiert werden. Ebenfalls nicht betroffen ist das Cloud-Angebot Exchange Online.

(Weitere) Angriffe verhindern

Da Angreifer die Schwachstellen bereits seit mehreren Tagen aktiv und massenhaft ausnutzen, empfiehlt sich vor der Suche nach einer möglichen Kompromittierung das folgende Vorgehen, um eine akute Infektion möglichst noch zu verhindern.

• Sofern eine Aktualisierung mit den von Microsoft bereitgestellten Sicherheitsupdates nicht möglich ist, sollten folgende Dienste umgehend deaktiviert werden:
  • Unified Messaging (UM)
  • Exchange Control Panel (ECP) VDir
  • Offline Address Book (OAB) VDir
  • ActiveSync
• Deaktivieren des OWA-Zugangs (Outlook Web Access): Zusätzlich empfiehlt sich die sofortige Sperrung von Port 443 an der Firewall beziehungsweise die Trennung des Exchange-Servers vom Internet bis zum Einspielen der Patches – sofern dies möglich ist und dies die Installation der Sicherheitsaktualisierungen nicht verzögert.

Überprüfen einer möglichen Kompromittierung

Erst danach sollten – ebenfalls so zeitnah wie möglich – Systeme auf eine etwaige Kompromittierung überprüft werden. Hier gehen Administratoren wie folgt vor:

1. Sichern der spezifischer Daten (durch eine Vollsicherung oder einen Snapshot inkl. Memory des Exchange-Systems) für eine spätere Analyse:
   • Exchange Server (Protokolldateien des IIS-Servers unter C:\inetpub\Logs, Protokolldateien des Exchange-Server unter <Exchange_Instalationspfad>\v15\Logging\ (mindestens ab dem 24.02), Inhalt des inetpub Ordners sowie sämtliche Windows Event Logs (C:\Windows\System32\winevt\logs\)
   • Domänen-Controller: sämtliche Windows Event Logs (C:\Windows\System32\winevt\logs\)
2. Offline-Sicherung (z. B. auf externe Festplatte) von Systemsicherungen (mindestens Exchange-System und Domänen-Controller vom letzten Sicherungsstand vor dem 02.03.2021).
3. Ausführen des Microsoft-Prüfskriptes (Test-ProxyLogon.ps1 und CompareExchangeHashes.ps1) gemäß Anleitung des Herstellers.

Als Ergebnis des letzten Schritts erhält man eine CSV-Datei, die es zu analysieren gilt. Sofern keine Einträge zu sehen sind oder nur solche mit der Endung 444/autodiscover/autodiscover.xml?#”,”200″, kann man Microsoft zufolge aktuell davon ausgehen, dass keine Kompromittierung stattgefunden hat. In diesem Fall sollten Unternehmen trotzdem prüfen, ob sie die unter „Vorbeugende Maßnahmen“ aufgeführten Empfehlungen umsetzten sollten.

Finden sich jedoch andere Einträge wie

• 444/mapi/emsmdb/?#”,”200″ oder
• 444/ecp/proxyLogon.ecp?#”,”241″

muss von einer Kompromittierung des Systems ausgegangen werden.

Ohne Microsoft Defender oder anderem Virenschutz, kann der Exchange Server auch mit dem kostenlosen Microsoft Safety Scanner aka Microsoft Support Emergency Response Tool (MSERT) auf bekannte Schadprogramme der Angreifer geprüft werden. Microsoft empfiehlt, dies als vollständige Prüfung durchzuführen. Der Defender erhielt bereits aktualisierte Signaturdateien zum Erkennen der bekannten Schadprogramme.

Vorgehen bei Verdacht auf Kompromittierung

Es ist aktuell noch nicht bekannt, zu welchem Zweck die Server attackiert werden. Auch hat sich die Zahl der Angreifergruppen seit der Veröffentlichung stark vergrößert. Aus diesem Grund lässt sich aktuell nicht abschätzen, welche Maßnahmen ausreichen, um die Systeme zu bereinigen. Dennoch haben wir ein Konzept entwickelt, um Server effektiv zu schützen.

Als ersten Schritt sollten Unternehmen überprüfen, ob zusätzlich zu den automatisierten Angriffen und dem möglichen Abgriff von Adressbüchern und E-Mails weitere Angriffe durchgeführt wurden. Ein besonderes Augenmerk sollte auf sogenannten „Webshells“ liegen. Das BSI bietet hierzu eine Übersicht „Microsoft Exchange Schwachstellen Detektion und Reaktion“, wie Administratoren nach Webshells suchen können.

Insbesondere die folgenden Verzeichnisse – inklusive ihrer Unterverzeichnisse – sollten sie auf zuletzt veränderte oder erstellte ASPX-Dateien (im letzten Monat) oder ASPX-Dateien, die dem Benutzer „NT AUTHORITY\SYSTEM“ gehören, testen:

• C:\inetpub\wwwroot\aspnet_client\
• <Exchange Installationspfad>\V15\FrontEnd\HttpProxy\owa\auth\
• C:\Exchange\FrontEnd\HttpProxy\owa\auth\

Die exakten Pfade können sich je nach Installationsort und Exchange-Version unterscheiden.

Zudem lassen sich die folgenden Tools nutzen, um Webshells aufzuspüren:

• Detektions-Skript für Webshells des lettischen CERT
• Thor-Lite Scanner mit den Signaturen unter:
  • https://github.com/Neo23x0/signature-base/blob/master/yara/apt_hafnium_log_sigs.yar
  • https://github.com/Neo23x0/signature-base/blob/master/yara/apt_hafnium.yar

Aufgrund der Vielzahl von möglichen Angreifern sollten diese Prüfung regelmäßig mit aktualisierten Signaturen wiederholt werden. Wurde eine Webshell gefunden, kann dies ein Indiz für eine tiefere Kompromittierung sein. Gemäß den BSI-Empfehlungen sollte man dann in den Incident-Response-Modus übergehen.

In jedem Fall sollte ein Backup des betroffenen Exchange-Servers (von vor dem 2.3.2021 bzw. vor dem festgestellten Kompromittierungsdatum) wiederhergestellt werden. Das System muss dabei zunächst vom Internet getrennt sein. Ein Zugriff auf die Domäne ist legitim, sofern notwendig. Eine sichere Eingrenzung des Angriffes ist dadurch allein allerdings nicht möglich, sodass weitergehende Optionen zu prüfen sind.

Vorbeugende Maßnahmen

Bei einer Kompromittierung oder einer späten Installation der Patches ist es auf jeden Fall ratsam, dass Verantwortliche die folgenden Maßnahmen durchführen, um mögliche Folgeangriffe zu verhindern oder mindestens zu erkennen:

1. Ausweiten der Protokollierung und Auswertung
2. Wöchentliches Überprüfen der Server mittels des Microsoft Safety Scanners
3. Systematisches Ändern von Zugangsdaten und Passwörtern, insbesondere bei administrativen Benutzerkonten
4. Überprüfen des Exchange Servers auf neu angelegte Benutzerkonten, Dienste oder zusätzlich ausgeführte Programme bzw. abgelegte Dateien
5. Sensibilisieren von Personal und Dienstleistern im Hinblick auf mögliche Phishing-Angriffe sowie CEO-Fraud-Szenarien
6. Vollständige Virenprüfung aller IT-Systeme
7. Kontinuierliches Monitoring des ein- und ausgehenden Traffics
8. Konsequenter Update Plan

Datenschutz prüfen

Da die Lage komplex und die Bewertung durch verschiedene Datenschutzbehörden unterschiedlich ist, ist zudem dringend die Notwendigkeit einer Meldung eines Datenschutzvorfalls zu prüfen. Je nach Bundesland gibt es hierzu unterschiedliche Auslegungen; vereinzelt wird sogar von einer Meldepflicht bei fehlenden Patches auch ohne Kenntnis eines Datenabflusses ausgegangen.

Gerne unterstützen wir sie bei der Umsetzung der Maßnahmen, sowie der Sicherung ihrer Systeme.