ProxyLogon-Hack: Repository für betroffene Exchange-Administratoren

[English]Was kann ich als Administrator von Exchange Servern angesichts der laufenden Angriffswellen auf die ProxyLogon-Schwachstellen tun? Was muss ich beachten? Wie finde ich heraus, ob die Instanzen bereits kompromittiert sind? Das Repository soll für Exchange-Administratoren eine Hilfestellung an die Hand geben, um schnell zu den wichtigsten Informationen zu gelangen.


Anzeige

Das Thema Exchange-Massenhack durch die Hafnium-Gruppe sowie die Problematik um die ProxyLogon-Schwachstellen schickt ja Schockwellen durch das Microsoft Eco-System. Aktuell nutzen mindestens zehn Bedrohungsakteure die Schwachstellen aus und versuchen Exchange Server, die per Internet erreichbar sind, zu kompromittieren. Von der Installation von Crypto-Minern, über das Stehlen von Informationen oder Eindringen in Active Directory-Strukturen bis hin zur Verteilung von Ransomware ist alles dabei. Das Thema wird sich noch lange beschäftigen. Wer für Exchange-Server verantwortlich ist, steht vor dem Frage: Wie die Installationen absichern und bin ich bereits kompromittiert?

Exchange Server identifizieren und ggf. vom Netz trennen

Im ersten Schritt ist sicherzustellen, dass alle On-Promises Exchange Server (Versionen 2010, 2013, 2016 und 2019) in der Unternehmensstruktur bekannt und deren Standorte identifiziert sind. Es sollte auch geprüft werden, ob der betreffende Exchange Server per Port 443 per Internet erreichbar ist – und falls ja, durch entsprechende Maßnahmen (Reverse Proxy mit Schutzmaßnahmen etc.) gesichert wurde. Falls nicht, empfiehlt es sich, den Exchange Server zumindest vorübergehend vom Internet zu trennen.

Palo Alto gibt hier an, dass es der erste Angriff die Fähigkeit erfordert, eine nicht vertrauenswürdige Verbindung zum Exchange Server-Port 443 herzustellen. Administratoren können sich dagegen schützen, indem Sie den Zugriff von nicht vertrauenswürdigen Benutzern auf das System einschränken. Dies kann erreicht werden, indem Administratoren den Zugriff auf das System nur von Benutzern erlauben, die sich bereits über ein VPN authentifiziert haben, oder indem eine Firewall verwendet wird, um den Zugriff auf bestimmte Hosts oder IP-Bereiche zu beschränken. Die Verwendung dieser Abschwächung schützt nur vor dem ersten Teil des Angriffs. Andere Teile der Kette können immer noch ausgelöst werden, wenn ein Angreifer bereits Zugriff auf das Netzwerk hat oder einen Administrator überzeugen kann, eine bösartige Datei zu öffnen.

Als nächstes sind alle Protokolle (Logs) zu sichern, um ggf. eine Kompromittierung überhaupt nachweisen und nachvollziehen zu können.

Ist der Exchange Server kompromittiert?

Ein ungepatchter und per Internet über Port 443 erreichbarer (und sonst ungeschützter) Exchange Server dürfte inzwischen durch eine Webshell als Backdoor oder andere Malware kompromittiert sein. Nach den obigen Maßnahmen empfiehlt sich daher die Prüfung, ob die Maschine bereits kompromittiert ist. Problem ist, dass diese Schwachstellen seit (möglicherweise) dem 3. Januar 2021 angegriffen werden. Wie kriege ich nun heraus, ob der Server bereits infiziert ist?

  • Microsoft hat im Artikel HAFNIUM targeting Exchange Servers with 0-day exploits einige Informationen zusammen getragen, wie der Angriff der Hafnium-Gruppe abläuft und welche Anzeichen es gibt.
  • Von Microsoft gibt es auf dieser GitHub-Seite einige PowerShell-Scripte, mit der sich einiges automatisiert überprüfen lässt. Speziell das PowerShell-Script Test-ProxyLogon.ps1 kann einen ersten schnellen Hinweis liefern, ob Hafnium aktiv war. Allerdings gibt es Leserhinweise, dass das Script bei Exchange Server 2010 auf Fehler läuft – und es werden wohl nur die Hafnium-Aktivitäten erkannt.
  • Die Sicherheitsforscher von ESET haben im Blog_Beitrag Exchange servers under siege from at least 10 APT groups das Ganze etwas weiter gefasst und beleuchten die Spuren von verschieden Angreifergruppen.
  • Palo Alto rät in diesem Artikel, das System auf verdächtiges Prozess- und Systemverhalten, insbesondere im Zusammenhang mit Internet Information Service (IIS) und Exchange-Anwendungsprozessen, wie PowerShell, Befehlsshells (cmd.exe) und andere Programme, die im Adressraum der Anwendungen ausgeführt werden, zu Überprüfen.
  • Von HighSolution Research gibt es einen Leitfaden im PDF-Format, der sich über diese Seite HiSolutions-Selbsthilfe-Hafnium kostenlos herunterladen lässt.

Bei heise gibt es den Artikel Exchange-Hack: Welche Maßnahmen Unternehmen jetzt ergreifen müssen, der ebenfalls einige Hinweise bezüglich einer Analyse gibt (deckt sich weitgehend mit dem HighSolution Research-Leitfaden).

Achtung: Microsoft hat zwar eine Erkennung der Schadsoftware im Defender eingebaut und auch das Microsoft Support Emergency Response Tool (MSERT) um Sicherheitsinformationen erweitert, um den Hafnium-Angriff zu erkennen (siehe mein Blog-Beitrag Microsoft MSERT hilft bei Exchange-Server-Scans). Aus heutigem Erkenntnisstand würde ich aber eher zu "Finger weg von MSERT" raten, denn ein Scan dürfte die Infektion und somit auch die Spuren für Analyse beseitigen, ohne die vollständige Bereinigung sicherzustellen. Denkbar wäre es, den Parameter /N für einen Read-Only-Scan zu verwenden (siehe auch nachfolgende Kommentare). Es bleiben aber die nachfolgenden Klippen.

Zudem wies Stefan Kathak auf die DLL-Hijacking-Schwachstelle in MSERT hin, so dass ein unbedarfter Administrator einer Malware unbewusst zu Administratorrechten verhilft.

Letzter Punkt für "Finger weg" sind Hinweise von Benutzern, dass das Tool ein merkwürdiges Verhalten zeigt. Es werden n Infektionen gemeldet, aber am Ende erklärt das MSRT das System für sauber. Die Log-Dateien sind auch leer. Wer scharf auf Herzinfarkt und Co. ist, mag mit dem Schätzeisen fuhrwerken – ich würde eher eine Bogen drum machen. Mehr Details hatte ich im Beitrag Neues zur ProxyLogon-Hafnium-Exchange-Problematik (12.3.2021) in einem separaten Abschnitt beschrieben.

Wird eine Infektion gefunden? Frank Carius hat in diesem Beitrag einige Gedanken dazu veröffentlicht. Seinen Empfehlungen zu MSERT setzt ihr meine obigen Hinweise und die nachfolgenden Kommentare entgegen und entscheidet dann. Seinen Empfehlungen, zum Neuaufbau folgt ihr, wenn sicher ist, dass keine weiteren Schritte erforderlich sind. Denn im Zweifelsfall müsste ein Forensik-Experte hinzugezogen werden, der prüft, was kompromittiert und an Informationen bereits abgezogen – und ob Active Directory-Strukturen bereits angefasst wurden. Wer alles vorher platt macht, braucht keinen Forensiker mehr.

Ergänzung: In Frankys Web gibt es inzwischen diesen Beitrag von Frank Zöchling. Die Kurzfassung lautet, dass vom HAFNIUM-Exploit ggf. Verzeichnisberechtigungen verändert werden. Dies führt dazu, dass betroffene Exchange Server eine Fehlermeldung bei der Installation von Updates melden. Details im verlinkten Beitrag.

Möglicherweise muss eine Infektion (binnen 72 Stunden) auch der zuständigen Datenschutzaufsicht gemeldet werden, da der Vorgang DSGVO-relevant sein kann. Hier hat sich die Redaktion von heise in diesem Beitrag zu geäußert.

Exchange Server patchen

Sind die obigen Fragen geklärt, ist sicherzustellen, dass die Exchange-Instanzen gegen die bekannten Schwachstellen CVE-2021-27065, CVE-2021-26855, CVE-2021-26857 und CVE-2021-26858 durch Sicherheitsupdates gepatcht sind.


Anzeige

Obwohl Exchange 2010 nicht für die gleiche Angriffskette anfällig ist wie Exchange 2013/2016/2019, hat Microsoft einen Patch für CVE-2021-26857 für diese Version der Software veröffentlicht. Hier ist nochmals die Liste der aktuellen Updates:

Bei der manuellen Installation der Sicherheitsupdates ist darauf zu achten, dass die Installation der Patches mit administrativen Benutzerrechten erfolgt. Alle erforderlichen die Maßnahmen sind in diesem Microsoft-Dokument sowie im Dokument Upgrade Exchange to the latest Cumulative Update beschrieben.

Falls der Exchange Server auf die Schnelle nicht gepatcht werden kann, lässt sich das Microsoft Dokument Microsoft Exchange Server Vulnerabilities Mitigations – updated March 9, 2021 verwenden, um temporäre Maßnahmen zur Reduktion des Risikos eines Angriffs zu ergreifen.

Anlaufstellen für eine Maßnahmenübersicht sind auch:

Die Informationen hier entsprechen dem Informationsstand 13. März 2021. Wichtig ist zu betonen, dass es nicht ausreicht, die Exchange-Instanzen zu patchen, um die Gefahr zu bannen, sondern es ist der nachfolgende Schritt zu durchlaufen. Vielleicht hilft es euch weiter.

Ähnliche Artikel:
Exchange-Server 0-day-Exploits werden aktiv ausgenutzt, patchen!
Wichtige Hinweise Microsofts und des BSI zum Exchange-Server Sicherheitsupdate (März 2021)
Exchange-Probleme mit ECP/OWA-Suche nach Sicherheitsupdate (März 2021)
Neues zum Exchange-Hack – Testtools von Microsoft & Co.
Microsoft MSERT hilft bei Exchange-Server-Scans
Exchange-Hack: Neue Patches und neue Erkenntnisse
Anatomie des ProxyLogon Hafinum-Exchange Server Hacks
Exchange-Hack: Neue Opfer, neue Patches, neue Angriffe
Neues zur ProxyLogon-Hafnium-Exchange-Problematik (12.3.2021)
Gab es beim Exchange-Massenhack ein Leck bei Microsoft?
ProxyLogon-Hack: Repository für betroffene Exchange-Administratoren
Microsoft Exchange (On-Premises) one-click Mitigation Tool (EOMT) freigegeben


Cookies blockieren entzieht uns die Finanzierung: Cookie-Einstellungen

Anzeige


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

16 Antworten zu ProxyLogon-Hack: Repository für betroffene Exchange-Administratoren

  1. Karl Wester-Ebbinghaus sagt:

    Danke Günter!

    Die Anzahl der Links und Länge der Artikel dürften ausreichend sein, um verständlich zu machen wie Komplex das Thema und Produkt Exchange ist.

    Hinweis:

    Prüfscripte sind weder fehlerfrei noch statisch, deshalb kann jeder auf github mit daran arbeiten. Neuere Versionen prüfen auf neue Erkenntnisse.
    Umso wichtiger wird es die Scripte nicht nur einmal laufen zu lassen (fire and forget) insb. Bei Servern die Treffer im Script aufweisen ist ratsam folgendes zu erwägen:

    Internen Datenschutzbeauftragte(n) einschalten. Meldepflicht berücksichtigen.

    Spurensicherung (AD / Exchange Backup)
    Scripte auch nach Absicherung in aktuellster Form periodisch prüfen lassen.

    Virenscanner (mit EDR) auf Servern installieren und Lösung aktiv überwachen.

    Ersten Eindruck gibt auch die 7 Tage Übersicht von Server Manager zum RAM und CPU verbraucht.

    Exchange und alle Server bishin zu Server 2022 sind auf Kompatibilität und nicht auf Sicherheit ausgelegt

    Betrifft
    SMB
    .net 3.5
    .net 4.x
    Schannel
    IE11 (Systemweit in Nutzung, nicht nur als Browser
    Winhttp
    PowerShell
    WinRM
    AD Passworthashes
    NTLM

    MSERT ist ein Schmalspur Signaturbasierter Scanner macht locker 2 vCores platt für Stunden bei Full scan

    Beim Patchen:
    Backup anfertigen

    C++ redists aktualisieren, alte deinstallieren. (sereby + Offizielle Seite für C++ 2015-2019)

    erst Windows Updates: SSUs + Updates
    Auch *optionale* Updates

    Dann dotnet 4.8 sofern supported und dann erst das aktuelle CU welches 4.8 supported.

    Siehe Exchange Matrix in en-us

    Es ist entgegen mancher Anweisung nicht gut die Exekutionpolicy auf unrestricted zu setzen.

    Msp aus cmd mit expliziten Admin rechten anwenden.

    Bei CUs temporär Organisations und Schema Adminrechte besitzen.

    AV abschalten trotz Ausnahmen. Es wurden schon einige Kundensysteme hierdurch beschädigt, weil der AV zu aggressiv war oder Windows Patches ebenso hemdsärmlig gemacht wurden.

    In Windows Update den Haken "Updates für andere Produkte aktivieren, geht ab Server 2016 per GPO mit aktuellen ADMX.

    Für die Zukunft:
    Security Guides anwenden

    Keine alten DC vor 2019 verwenden, aktuelles AD Level benutzen.
    Kennwörter ändern (auch in gleiche wenn notwendig)
    Dies generiert z. B. ab AD 2008R2 DFL neue Hashes mit sicheren Methoden (vorher RC4)

    Siehe Steve Syfuhs Blog zu NTLM und Kerberos.
    Server nicht mehr manuell patchen, sondern orchestiert bestenfalls in Woche 3 oder 4 eines Monats. WU/WUfB oder WSUS reichen dafür aus.

    die offizielle Dokumentation und techcommunity.microsoft.com lesen

    Server Core nutzen

    Hardening der o.g. Komponenten ist nach Tests ratsam. Änderungen vom Default dokumentieren. Dies betrifft auch die Default Domain und Controller Policy in Bezug auf NTLM.

    Alte Systeme hinreichend isolieren

    Wem das zuviel Arbeit erscheint > Exchange online, ist auch keine Wunderheilung wg. AD Connect Absicherung, Multifaktor, on prem Management Tools (Exchange 2016) müssen auch gepacht werden (ggf nicht in diesem Kontext, je nach autodiscover), etc.

    Die Lücke, selbst wenn geschlossen, aber zuvor genutzt, ist groß genug um ein System vollständig und auch recht "lautlos" zu kompromittieren und zwar dank den Default Einstellungen der o.g. Systeme und der engen Verbindung von Exchange zum AD.

    • 1ST1 sagt:

      Man könnte das hier fast schon als Exchange-Hardening-Guide bewerben.

      [++++++++++++++++++++++++++++++++++++]

    • Martin Feuerstein sagt:

      >> Es ist entgegen mancher Anweisung nicht gut die Exekutionpolicy auf unrestricted zu setzen.

      Bei den Exchange-Updates und CUs muss zur Installation die Policy häufig gelockert werden, also z. B. RemoteSigned anstatt AllSigned oder Restricted. Aber klar, nicht dauerhaft auf unrestricted stehen lassen.

    • Günter Born sagt:

      Zudem gibt es noch diesen heise-Kommentarthread mit einigen Hinweisen zur Prüfung – die meisten der Folgekommentare kann/sollte man überspringen – zum MSERT bitte obige Hinweise lesen und selbst entscheiden.

    • Blubmann sagt:

      Welches System verwendet ihr zum orchestrieren von Windows Updates? Ich habe Ansible, aber bin nicht so glücklich damit, da man doch sehr viel Zeit zum Einlernen reinstecken muss.

  2. Michael sagt:

    MSERT erzeugt nur unvollständige Logs wenn man es während des Scan vorzeitig abbricht (so meine Erfahrung). Und noch ein Tipp: CMD.exe als Admin starten und bei MSERT.exe den Schalter /N verwenden für Read-Only-Scan, d.h. es wird nur gesucht und nicht gleich gelöscht. Und ja, warum das mit /N selbst Microsoft nicht deutlich dokumentiert ist mir ein Rätsel…

  3. OlliD@IRQ8 sagt:

    Zusätzlicher Forensic-Scanner: THOR Lite (Nextron Systems GmbH
    Bruchstrasse 8, 63128 Dietzenbach, Germany): https://www.nextron-systems.com/thor-lite/

  4. stefan seidl sagt:

    also irgendwie is doch da der wurm drinnen, grade auf nem NEU installieren ex2016, der von extern weder auf port25 noch auf 44 ereichbar ist, das aktuelle Test-ProxyLogon ausgeführt und *oh WUNDER* er hat was gefunden:

    ProxyLogon Status: Exchange Server EX16
    Log age days: Oabgen 0,0 Ecp 0,0 Autod 0,1 Eas 0,1 EcpProxy 0,1 Ews 0,1 Mapi 0,1 Oab 0,1 Owa 0,1 OwaCal 0,1 Powershell
    0,1 RpcHttp 0,1
    Report exported to: C:\Users\administrator\Downloads\Test-ProxyLogonLogs\EX16-LogAgeDays.csv
    [CVE-2021-27065] Suspicious activity found in ECP logs!
    Please review the following files for 'Set-*VirtualDirectory' entries:
    C:\Program Files\Microsoft\Exchange Server\V15\Logging\ECP\Server\ECPServer20210314-1.LOG
    Report exported to: C:\Users\administrator.GREGER\Downloads\Test-ProxyLogonLogs\EX16-Cve-2021-27065.log

    exchange 2016 cu 19 inkl installieren KB5000871 ??!!

    sorry aber was soll das nu wieder ? installier seit freitag nachmittag mehrere ex neu.. hätte ich wohl sparen können ;)

    • Stefan A. sagt:

      Das würde ja bedeuten, dass der Angreifer bereits intern wo sitzt und der Server von intern bereits wieder angegriffen wurde…
      Denn ohne 443 von extern, muss es ja von intern kommen…

      • Stefan Seidl sagt:

        Oder das die Scripte einfach nur Mist machen wär keine Alternative??

        • Stefan A. sagt:

          Darüber habe ich noch gar nicht nachgedacht.

          Microsoft schreibt ja:
          „ All Set-VirtualDirectory properties should never contain script. InternalUrl and ExternalUrl should only be valid Uris"

          https://www.microsoft.com/security/blog/2021/03/02/hafnium-targeting-exchange-servers/

          Wäre mal interessant, was er dann in der CSV genau aufführt als „entdeckte Zeile".

          Vielleicht generiert er beim Setup generell solche Einträge.

          Das ist aber gerade nur eine wage Vermutung!

          Vielleicht kann ja jemand anderes mehr dazu sagen.

          • Jan sagt:

            Hatte ich auch gerade, er erkennt das Setzen der internen und externen URLs für die virtuellen Verzeichnisse. Ich habe die Log gelöscht, damit ich später nicht jedes mal erschrecke.

            Leider läuft mein Server noch nicht ganz rund. Der WinRM ist der Meinung, es darf Port 443 beim Start verwenden und nimmt den Port dem IIS weg. Ich habe WinRM nun auf manuell gestellt, wenn man es dann später startet, ist alles ok.

  5. 1ST1 sagt:

    Auch das Paul Ehrlich Institut in Langen ist vom Exchange-Hack betroffen, und das ausgerechnet in der Corona-Pandemie.

    https://www.spiegel.de/netzwelt/web/microsoft-schwachstelle-impfstoff-experten-vom-paul-ehrlich-institut-betroffen-a-8e3a428f-2a36-4297-98d6-c4d82c461d24

  6. Günter Born sagt:

    Bei administrator.de hat noch jemand diesen Kommentar mit Maßnahmen bei einer Infektion hinterlegt – vielleicht von Interesse.

  7. Karl Wester-Ebbinghaus sagt:

    Danke an alle und Günter.

    Es gibt nun ein neues Tool von Microsoft zur Prüfung.

    Den Kommentar hab ich gelesen.

    "Mal drüber nachdenken: Wenn ich behaupte, dass auch Geräte wie Drucker befallen sind, setzt das nicht voraus, dass die Angreifer wissen, um welche Druckermodelle es sich handelt? Das ist aus meiner Sicht automatisiert nur begrenzt zu machen, gibt schließlich mehr als ein Modell. Im Zweifel hat ein Angreifer sich im Netz schon mal genauer umgesehen und Informationen gesammelt."

    Wer einmal die Möglichkeiten von portable Softperfect Network Scanner gesehen hat und die des Switch Port Scanners hat in Minuten bis Stunden alles fein säuberlich rausgefunden inkl der Druckermodelle

    Ich sag nur wieder Defaults

    PowerShell /Winrm
    IPP
    LNMNR
    CDP, STP und ähnliches
    SNMP

    Nur wenige Unternehmen, bezogen auf KMU und können das alles absichern. Und diese scans werden auch von Sophos / XDR nicht per se geblockt.

    Es ist erstaunlich warum so viele Arbeit in Excel stecken. Man bekommt wirklich kompletten Eindruck über die Infrastruktur, offene Ports, Loginbanner, SMB shares, angemeldete User, etc pp., detaillierter Netzwerkaufbau Firmware und Switch Modelle etc, OS Versionen und somit weitere Lücken.

    Mindestens teilautomatisiert.

    "also irgendwie is doch da der wurm drinnen"

    Wuemfähige Angriffe sind besonders toll. Danke Stefan.

  8. Coreknabe sagt:

    @ Karl Wester-Ebbinghaus
    Zitat: Wer einmal die Möglichkeiten von portable Softperfect Network Scanner gesehen hat und die des Switch Port Scanners hat in Minuten bis Stunden alles fein säuberlich rausgefunden inkl der Druckermodelle

    Das ist korrekt, bedingt aber, dass UPnP aktiviert ist und sowas sollte man in einem Unternehmensnetzwerk tunlichst unterlassen. Ich verweise auf das Handbuch des Softperfect Network Scanners:
    https://www.softperfect.com/products/networkscanner/manual/

    Hier heißt es u.a.:
    UPnP device detection

    Furthermore, the application can discover Universal Plug and Play (UPnP) devices in your network such as media servers, routers and printers. Similarly to the DHCP discovery, it broadcasts a UPnP discovery message and collects replies from compatible devices. To see your UPnP devices, choose Actions – UPnP Device Discovery from the main menu. Click a Device User Interface URL to access the device.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.

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