123290

07.03.2021

13795

109

Exchange Zero Day Hack - Wie entfernen?

Hallo, bei mir hat es einige Kundenserver getroffen... Weiß einer wie ich diese WebShells wieder loswerde? Das löschen der betroffenen .aspx Dateien wird wohl kaum reichen. Bitte sagt jetzt nicht Datensicherung, das Kind ist ja schon in den Brunnen gefallen und es wäre zumindest die Frage Wert man nicht doch einen Reparaturversuch starten kann bevor ich jetzt Tage durch die Rücksicherung verliere...

Wo klinkt sich das alles ein wo man suchen muss? Ich habe jetzt von IIS und AD so ziemlich alles gefunden - nur keine konkreten Aussagen

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 660326

Url: https://administrator.de/contentid/660326

Ausgedruckt am: 19.11.2024 um 11:11 Uhr

109 Kommentare

Neuester Kommentar

Hi mtaiit,

schau mal hier nach.

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

Gruss Alex

Erste Maßnahme: Diese Systeme sofort vom Netz nehmen!

Wo klinkt sich das alles ein wo man suchen muss?

Da die Tools Webshells auf den Servern öffnen sind sie potenziell mit allem möglichem infiziert und nicht nur auf die Webshells beschränkt die bekannt sind. Ein infizierter Server kann also nicht mehr zu 100% vertraut werden auch wenn die im Link beschriebenen Dinge entfernt wurden, denn die Shells können ja alle möglichen weiteren Dinge installieren.
Die einzig richtige und vertrauenswürdigste Maßnahme (auch wenn sie manch einem weh tut) ist also so ein System sauber neu aufzusetzen und die Daten aus dem Backup einzuspielen, gerade bei Kundensystemen will ich nicht das Risiko eingehen das sich doch noch etwas eingenistet hat das durch den ITler oder die SEC-Suite übersehen wurde, denn dann ist die Kacke richtig am dampfen, nicht nur für den Kunden sondern auch für euch als Dienstleister.

Gruß SK

Zitat von @147669:

Die einzig richtige und vertrauenswürdigste Maßnahme (auch wenn sie manch einem weh tut) ist also so ein System sauber neu aufzusetzen und die Daten aus dem Backup einzuspielen, gerade bei Kundensystemen will ich nicht das Risiko eingehen das sich doch noch etwas eingenistet hat das durch den ITler oder die SEC-Suite übersehen wurde, denn dann ist die Kacke richtig am dampfen, nicht nur für den Kunden sondern auch für euch als Dienstleister.

Das kann ich nur bestätigen. Denn ein kompromittiertes System kann viele versteckten Zeitbomben enthalten, die so erstmal nicht auffällig sind.

Und ja, das tut weh, ist Aufwand und kostet den Kunden ordentlich Geld.

Aber das Risiko wäre mir persönlich zu hoch.

lks

Zitat von @123290:
Bitte sagt jetzt nicht Datensicherung, das Kind ist ja schon in den Brunnen gefallen und es wäre zumindest die Frage Wert man nicht doch einen Reparaturversuch starten kann bevor ich jetzt Tage durch die Rücksicherung verliere...

Moin,
Wenn du in der Lage bist forensiche Analysen der Systeme zu machen kannst du dich ja mal daran versuchen, halte ich allerdigns für die größere Zeitverschwendung. Wichtiger wäre herauszufinden wann die Systeme infiziert wurden und zu schauen das man ein älteres Backup hat oder alternativ neu zu installieren.

/Thomas

Ich habe mich jetzt recht lange durch die Microsoft Docs gearbeitet - bin fast an jeder Stelle fündig geworden. Damit gebe ich euch recht das hier einfaches entfernen überhaupt nicht mehr ausreichend ist. Zumindest kann ich anhand der Ereignisanzeige ziemlich genau feststellen (in meinem Fall der 3. März 1:20 Uhr) ab wann das hacken genau losging und kann jetzt die Sicherung vom Vorabend zurückholen.

Habt ihr was gelesen was genau alles entwendet wird? Meldung beim Datenschutz wird wohl nötig sein, stimmts?

Moin,

habe zur Prüfung eines Exchange 2019 gerade das folgende Skript erstellt.

#HAFNIUM
#Scan Exchange log files for indicators of compromise
#Detect CVE-2021-26855
Import-Csv -Path (Get-ChildItem -Recurse -Path "$env:PROGRAMFILES\Microsoft\Exchange Server\V15\Logging\HttpProxy" -Filter '*.log').FullName | Where-Object {  $_.AuthenticatedUser -eq '' -and $_.AnchorMailbox -like 'ServerInfo~*/*' } | select DateTime, AnchorMailbox  

#Detect CVE-2021-26858
findstr /snip /c:"Download failed and temporary file" "%PROGRAMFILES%\Microsoft\Exchange Server\V15\Logging\OABGeneratorLog\*.log"  

#Detect CVE-2021-26857
Get-EventLog -LogName Application -Source "MSExchange Unified Messaging" -EntryType Error | Where-Object { $_.Message -like "*System.InvalidCastException*" }  

#Detect CVE-2021-27065
Select-String -Path "$env:PROGRAMFILES\Microsoft\Exchange Server\V15\Logging\ECP\Server\*.log" -Pattern 'Set-.+VirtualDirectory'  

#Detect malicious web shells
Get-ChildItem -Path C:\inetpub\wwwroot\aspnet_client\ -Include web.aspx, help.aspx, document.aspx, errorEE.aspx, errorEEE.aspx, errorEW.aspx, errorFF.aspx, healthcheck.aspx, aspnet_www.aspx, aspnet_client.aspx, xx.aspx, shell.aspx, aspnet_iisstart.aspx, one.aspx -Recurse | Select-Object Fullname
Get-ChildItem -Path C:\inetpub\wwwroot\aspnet_client\system_web\ -Include web.aspx, help.aspx, document.aspx, errorEE.aspx, errorEEE.aspx, errorEW.aspx, errorFF.aspx, healthcheck.aspx, aspnet_www.aspx, aspnet_client.aspx, xx.aspx, shell.aspx, aspnet_iisstart.aspx, one.aspx -Recurse | Select-Object Fullname
Get-ChildItem -Path "%PROGRAMFILES%\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\owa\auth\" -Include web.aspx, help.aspx, document.aspx, errorEE.aspx, errorEEE.aspx, errorEW.aspx, errorFF.aspx, healthcheck.aspx, aspnet_www.aspx, aspnet_client.aspx, xx.aspx, shell.aspx, aspnet_iisstart.aspx, one.aspx -Recurse | Select-Object Fullname  
#this path is not available for every exchange
Get-ChildItem -Path C:\Exchange\FrontEnd\HttpProxy\owa\auth\ -Include web.aspx, help.aspx, document.aspx, errorEE.aspx, errorEEE.aspx, errorEW.aspx, errorFF.aspx, healthcheck.aspx, aspnet_www.aspx, aspnet_client.aspx, xx.aspx, shell.aspx, aspnet_iisstart.aspx, one.aspx -Recurse | Select-Object Fullname

Wenn man die Pfade anpasst, dann funktioniert es auch bei den älteren Exchange Servern.

Grüsse aus BaWü
Alex

Unter dem folgenden Link gibt es auch noch wichtige Hinweise.

https://msrc-blog.microsoft.com/2021/03/05/microsoft-exchange-server-vul ...

Allgemeiner Tip für alle betroffenen: Ich habe jetzt alle Einträge der Ereignisanzeige durchgelesen und kann sagen: Der Hack ist überall. Im IIS, Änderungen von Gruppen in der AD und auch merkwürdige DNS-Dienst Änderungen und Neustarts. Dazu komisches Verhalten zweier Nutzer beim Email Versand mitten in der Nacht... (ungültige oder zuviele Zeichen der Nachricht - hä?!?)

Abschließend: Suchen in der Ereignisanzeige wann es anfing, Vollsicherung zurück, alle CUs und Patch einspielen und wo möglich: Port 443 dicht. Jeden Tag was neues in der IT Welt...

Wäre interessant zu wissen, welche Änderungen konkret auffielen.
- Welche Gruppen wurden geändert? - Wie? (wir wissen aus den KB dass die Org-Admin manipuliert werden sollte, hier sind wir gehärtet.)
- Welche DNS-Dienständerungen sind erfolgt?
- Welche Neustarts gab es
- Konkrete Ereignislog IDs, Meldungen

Außerdem das Setup. Sprechen wir hier von Netzen nach Schema Fritzbox -> natted 443 -> Ex oder sprechen wir hier von Reverse Proxy secured?

Wir untersuchen derzeit vereinzelte Angriffsversuche, wobei wir nach akribischer Untersuchung von Systemänderungen (Dateien, Monitoring, inkl. Eventlog, Zugriffen etc), kein Änderung oder maliziöses Verhalten (s.o. Mails, Datenabfluss, Abfragen) feststellen mussten. Allerdings sind diese Systeme auch nach Schema b aufgebaut.

Port 443 komplett dicht wird nicht funktionieren.

Tendenziell denken wir, dass dieser Zero-Day aus den Lagern der NSA letzten/vorletzten Monat entwendet wurde.

DNS: Der Dienst wurde mitten in der Nacht nach dem Hack zwei mal von einem Systemkonto neu gestartet, Änderungen habe ich nichts gefunden was mir ins Auge sticht

AD: Was genau geändert wurde konnte ich leider nicht finden - irgendwas mit sicheren und unsicheren Anmeldeverfahren

Schema: Router -> Portweiterleitung 443 -> Server

Im Anhang mal ein paar Bilder was jetzt oft zu finden ist bzw mir ins Auge sticht. Dieses Script mit http://g..... wurde bei mir von TrendMicro als gefährlich geblockt

Hallo Kollegen,
bei Kunden mit Reverse Proxy und DMZ scheint alles in Ordnung zu sein,
hier verhaltet sich laut Monitoring auch noch alles ruhig...

Bei einem Kunden mit NAT schlägt der Scan zwar an :
https://github.com/microsoft/CSS-Exchange/tree/main/Security

Aber es sind keine ASPX Datein in C:\\inetpub\wwwroot\aspnet_client\system_web\ vorhanden so wie Chris Krebs es beschreibt.
Das oben genannte Tool von Github erstellt auch CSV-Datein in denen Sowas steht:

2021-03-06T13:59:26.269Z,"2953d0df-16b2-4131-9ced-854e19453e74","14.52.13.139","publicIPdesKunden","/ecp/x.js","X-BEResource-Cookie","python-requests/2.25.1","ServerInfo~akak]@exchangedeskunden.domain:444/ecp/DDI/DDIService.svc/SetObject?msExchEcpCanary=wIMkAZ5vakqiNtORC3DPfW3M_0464tgIo0aRSNBKf54AyAhi10MRyLIoVneSJXax1CO2J5t93co.&schema=OABVirtualDirectory#","200"  

14.52.13.139

Stammt wohl aus Korea...

Ich weiß mit dem Ergebnis der CSV relativ wenig anzufangen, könnt ihr mir hier weiterhelfen? Wie sind diese Einträge zu deuten?
Scheint wohl eine Woche mit viel Arbeit zu werden..

Dann gibts noch eine Exchange-other CSV in denen auf Prozesse des eingesetzten Virenschutzes verwiesen wird.

Beste Grüße an euch

Wir haben vor unseren EXCH auch einen Reverse Proxy (die Squid-Anleitung von @Dani mit einigen Anpassungen) und bei der Prüfung heute ist nichts aufgefallen. Gepatcht wurde bereits am Donnerstag. Alle unsere vier Kisten (2x 2010, 2x 2013) sind offensichtlich sauber.

Wir machen aber eine AD-Auth bereits am Squid, die dann an die XNG durchgereicht wird, somit kommt man ohne gültige Anmeldung gar nicht erst an die EXCH dran.

Moin,

Zitat von @tikayevent:

Wir haben vor unseren EXCH auch einen Reverse Proxy (die Squid-Anleitung von @Dani mit einigen Anpassungen) und bei der Prüfung heute ist nichts aufgefallen. Gepatcht wurde bereits am Donnerstag. Alle unsere vier Kisten (2x 2010, 2x 2013) sind offensichtlich sauber.

Bei uns läuft auch der Exchange (2016 CU19) hinter einem Reverse Proxy (Sophos).
"Gehärtet" wurde alles gemäß Frank Zöchler: https://www.frankysweb.de/sophos-utm-9-4-waf-und-exchange-2016/ und noch ein bisschen Feintuning obendrein...
Patch wurde am Mittwoch Nachmittag eingespielt.

Kontrolle der Systeme gestern und heute: Nirgends "irgendwelche" Funde - zum Glück.

Gruß
em-pie

Vom BSI

"Eine mögliche Shell wurde z. B. unter %PROGRAMFILES%\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy
\owa\auth\ als RedirSuiteServerProxy.aspx abgelegt. Generell sind alle kürzlich erzeugten .aspx-Dateien
verdächtig. Allerdings könnte eine Webshell auch in bestehende Dateien hinzugefügt werden, indem eine einzige
Zeile eingefügt wird. Hinweis: Die RedirSuiteServiceProxy.aspx ist grundsätzlich legitim."

RedirSuiteServiceProxy.aspx ist bei uns vorhanden aber von 2019. Sehe ich das richtig das nur Rechner mit offenem 443 zum Exchange betroffen sind?

"Das Risiko erfolgreicher Angriffe besteht insbesondere für alle aus dem Internet erreichbaren Exchange-Server (z. B.
im Falle einer Erreichbarkeit via Outlook Web Access (OWA)), wenn die Verbindung nicht ausschließlich mittels VPN
erfolgt.
Laut der Server-Suchmaschine Shodan betrifft die Schwachstelle potentiell etwa 57000 Server in Deutschland
[TWI2021b]."

Moin em-pie,

habe vor drei Wochen einen neuen Exchange 2019 mit CU8 in Betrieb genommen.
Dieser wird ebenfalls vor einer Sophos WAF (XG) geschützt, der MS Patch wurde am Freitag eingespielt.
Die Nachkontrolle heute ergab, das Ding ist infiziert. 🤢🤮

Bin gerade am Bereinigen, drückt mir die Daumen.

Bei diesem Exchange-Server war die remote Shell im folgenden Pfad versteckt.
"C:\inetpub\wwwroot\aspnet_client\discover.aspx"

Bitte alle Exchange-Server mit dem folgenden Tool von MS zusätzlich zum AV durchscannen!!!

https://docs.microsoft.com/en-us/windows/security/threat-protection/inte ...

Grüsse aus BaWü

Alex

Zitat von @MysticFoxDE:
Bitte alle Exchange-Server mit dem folgenden Tool von MS zusätzlich zum AV durchscannen!!!

https://docs.microsoft.com/en-us/windows/security/threat-protection/inte ...

Grüsse aus BaWü

Alex

Danke...

https://msrc-blog.microsoft.com/2021/03/05/microsoft-exchange-server-vul ...

"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."

Zitat von @MysticFoxDE:
Bin gerade am Bereinigen, drückt mir die Daumen.

Moin,

die spannende Frage ist halt ob du den noch bereinigen kannst, mit der Shell können die ja alles mögliche angestellt haben.

/Thomas

Moin,
Microsoft stellt ein PowerShell Skript zur Überprüfung bereit: CSS-Exchange

Gruß,
Dani

Hallo,

könntest Du beschreiben was Du im AD und DNS gefunden hast?

Bei 2 meiner Kunden habe ich mit dem Skript Einträge gefunden.
Aber weder diese ASPX-Daiten noch neue Benutzer im AD/Exchange oder geänderte Exchange- oder DNS-Einstellungen.
Dazu aber viele Log-Einträge von ESET dass er Zugriffe unterbunden hat, bzw. Dateien gelöscht hat.
Ich bin alles durchgegangen was mir so einviel, habe aber nichts gefundenn.

Klar
Zero Day Exploit, Möglicherweise schon weit vor der Meldung von Microsoft und deren Updates.
Besser wäre ein Backup zurückspielen. Aber zu wann?

Es kann ja noch andere Exploits gegeben haben der schon vor Wochen lief und nicht erkannt wurde bis jetzt.

Hallo,

ich habe gerade diese Datei gefunden
C:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\owa\auth\OutlookCN.aspx
Erstellt/Geändert am 19.11.2020 (Datum durch Datensicherung bestätigt)

Und eine "getidtoken.htm" von 2018.

Was kann ich davon halten?
Panik oder gehört das zum Exchange?

Das Skript von MS zeigt keine Auffälligkeiten.

Stefan

PS: Wer das PDF vom BSI nicht gelesen hat.
Stufe 4/Rot = Die IT-Bedrohungslage ist extrem kritisch. Ausfall vieler Dienste, der Regelbetrieb kann nicht aufrecht erhalten werden

Das Script MS gibt bei uns einen Treffer. Keine der bisher bekannten Pfade zeigt die Shell Dateien oder andere Auffälligkeiten.

Im Report vom MS Script stehen Zeilen wie diese

2021-03-06T09:44:49.629Z,"b7564c28-6143-447b-bd91-6a9fde1579dd","144.91.94.195","XXXXXXX","/owa/auth/x.js","X-AnonResource-Backend-Cookie","Mozilla/5.0 (Windows NT 10.0  
2021-03-06T13:20:49.338Z,"99bebb23-a938-4764-b57c-49b8af5a2184","144.91.94.195","XXXXXXX","/owa/auth/x.js","X-AnonResource-Backend-Cookie","Mozilla/5.0 (Windows NT 10.0  
2021-03-06T16:03:36.860Z,"e49e643b-9f77-43de-a24a-0c672ca84e9d","104.225.219.16","business-XXXX","/owa/auth/x.js","X-AnonResource-Backend-Cookie","Mozilla/5.0 (compatible  
2021-03-07T01:22:57.095Z,"7fb1d1c0-de3b-46dd-97d9-7cbfd41d5150","159.89.95.163","XXXXXXX","/owa/auth/x.js","X-AnonResource-Backend-Cookie","Mozilla/5.0 zgrab/0.x","ServerInfo~localhost/ecp/default.flt?","500"  
2021-03-07T11:09:33.370Z,"535d1a29-28fe-4256-bc51-0517e7181fd4","113.173.3.225","XXXXXXX","/owa/auth/x.js","X-AnonResource-Backend-Cookie","Mozilla/5.0 (Windows NT 10.0  
2021-03-07T11:50:19.323Z,"998f1351-9a79-432b-a1e2-ed8d04d00d2a","104.225.219.16","business-XXXXXp.net","/owa/auth/x.js","X-AnonResource-Backend-Cookie","Mozilla/5.0 (compatible  
2021-03-07T15:26:53.105Z,"756a0d3a-50b0-4148-b8c6-1f6d329e2351","144.91.94.195","XXXXXXX","/owa/auth/x.js","X-AnonResource-Backend-Cookie","Mozilla/5.0 (Windows NT 10.0  

Was denkt ihr? Abschalten und neu aufsetzen?

Zitat von @B4dmin:
Was denkt ihr? Abschalten und neu aufsetzen?

https://blog.rapid7.com/2021/03/03/rapid7s-insightidr-enables-detection- ...
Schau mal hier.
Erstmal wäre ein Cookie nur ein Cookie für mich.
Wichtig wäre die Zahl am Ende. Wenn da ein 404 oder 403 steht wäre es ganz egal.

Was meinst du mit Zahl am Ende?

anbei mal die komplette Zeile:

2021-03-07T11:50:19.322Z,"998f1351-9a79-432b-a1e2-ed8d04d00d2a","104.225.219.16","localhost","/ecp/default.flt","X-BEResource-Cookie","Mozilla/5.0 (compatible	 Nmap Scripting Engine	 https://nmap.org/book/nse.html)","ServerInfo~localhost/owa/auth/logon.aspx?","500"	  
2021-03-06T09:44:49.629Z,"b7564c28-6143-447b-bd91-6a9fde1579dd","144.91.94.195","XXXXXXX","/owa/auth/x.js","X-AnonResource-Backend-Cookie","Mozilla/5.0 (Windows NT 10.0	 rv:68.0) Gecko/20100101 Firefox/68.0","ServerInfo~burpcollaborator.net/ecp/default.flt?","200"		  
2021-03-06T13:20:49.338Z,"99bebb23-a938-4764-b57c-49b8af5a2184","144.91.94.195","XXXXXXX","/owa/auth/x.js","X-AnonResource-Backend-Cookie","Mozilla/5.0 (Windows NT 10.0	 rv:68.0) Gecko/20100101 Firefox/68.0","ServerInfo~burpcollaborator.net/ecp/default.flt?","200"		  
2021-03-06T16:03:36.860Z,"e49e643b-9f77-43de-a24a-0c672ca84e9d","104.225.219.16","XXXXXXX.static.arcor-ip.net","/owa/auth/x.js","X-AnonResource-Backend-Cookie","Mozilla/5.0 (compatible	 Nmap Scripting Engine	 https://nmap.org/book/nse.html)","ServerInfo~localhost/ecp/default.flt?","500"	  
2021-03-07T01:22:57.095Z,"7fb1d1c0-de3b-46dd-97d9-7cbfd41d5150","159.89.95.163","XXXXXXX","/owa/auth/x.js","X-AnonResource-Backend-Cookie","Mozilla/5.0 zgrab/0.x","ServerInfo~localhost/ecp/default.flt?","500"			  
2021-03-07T11:09:33.370Z,"535d1a29-28fe-4256-bc51-0517e7181fd4","113.173.3.225","XXXXXXX","/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~localhost/ecp/default.flt?","500"  
2021-03-07T11:50:19.323Z,"998f1351-9a79-432b-a1e2-ed8d04d00d2a","104.225.219.16","XXXXXXX.static.arcor-ip.net","/owa/auth/x.js","X-AnonResource-Backend-Cookie","Mozilla/5.0 (compatible	 Nmap Scripting Engine	 https://nmap.org/book/nse.html)","ServerInfo~localhost/ecp/default.flt?","500"	  
2021-03-07T15:26:53.105Z,"756a0d3a-50b0-4148-b8c6-1f6d329e2351","144.91.94.195","XXXXXXX","/owa/auth/x.js","X-AnonResource-Backend-Cookie","Mozilla/5.0 (Windows NT 10.0	 rv:68.0) Gecko/20100101 Firefox/68.0","ServerInfo~burpcollaborator.net/ecp/default.flt?","200"		  

500 = Serverfehler
200 = Zugriff erfolgreich, Die Datei wurde aufgerufen
Aber Javascript läuft im Browser und nicht auf dem Server

Strange

Moin,
was ist das Ergebnis des Nmap Skripts von Microsoft?

Gruß,
Dani

Moin Dani,

bei mir sagt Nmap.

😀

Der befallene Exchange unseres Kunden ist wieder sauber, ich kriech jetzt in den Fuchsbau und penne mal ne runde.

Grüsse aus BaWü

Alex

Moin Thomas,

die spannende Frage ist halt ob du den noch bereinigen kannst, mit der Shell können die ja alles mögliche angestellt haben.

das kann schon sein, dass die Üblinge alles mögliche mit der remoteshell anstellen könnten, aber deren Spielwiese ist gar nicht so unendlich wie man denkt. Habe das System und die üblichen Verstecke "abgetastet" und habe bisher nichts gefunden.
Sieht so aus, als ob die in diesem Fall zwar die remoteshell implementiert aber noch nicht aktiv benutzt haben. 😌

Dennoch bleibt der https Zugang dieses Servers sicherheitshalber erstmal offline, bis bei allen Account in der betroffenen Domäne die Passwörter geändert wurden.

Grüsse aus BaWü
Alex

Zitat von @MysticFoxDE:

Moin Dani,

bei mir sagt Nmap.

😀

Der befallene Exchange unseres Kunden ist wieder sauber, ...

Hoffest Du.

ich kriech jetzt in den Fuchsbau und penne mal ne runde.

Gute Nacht/Guten Morgen.

lks

Hattest du also gar nichts auf dem System gefunden @alex

Moin B4dmin,

Hattest du also gar nichts auf dem System gefunden @alex

auf dem betroffenen Exchange, war wie ich schon oben geschrieben habe die remoteshell bereits drauf.
Diese habe ich selbstverständlich gelöscht.

Ansonsten habe ich nach stundenlangem Suchen absolut nichts gefunden.

Das ist auch nicht ungewöhnlich. Das Unterwandern der Systeme und das Ausrollen von Backdoors geschieht meist automatisiert.
Ist ein System automatisiert unterwandert worden, dann kommt es auf eine Liste und wird danach je nach Wichtigkeit meistens manuell
weiter bearbeitet. Der betroffenen Exchange war zum Glück, was das manuelle Weiterbearbeiten angeht, einfach noch nicht dran.

Grüsse aus BaWü
Alex

Moin lks,

Hoffest Du.

ich glaube schon, dass der Exchange wieder sauber ist.
Dennoch werde ich diesen, die nächsten Tage/Wochen auf jeden Fall im Blick behalten.
Wie heisst es so schön, Vertrauen ist gut, Kontrolle ist besser. 🙃
(Ich hoffe nur, dass keine weiteren dazukommen)

Grüsse aus BaWü
Alex

Moin und danke für die Hilf,

auf dem betroffenen Exchange, war wie ich schon oben geschrieben habe die remoteshell bereits drauf.
Diese habe ich selbstverständlich gelöscht.

welcher Pfad was es in deinem Fall?

bei nmap gibt es bei mir das gleiche Ergebnis wie bei dir, bis auf diese Cookies hat das MS Script nichts gefunden bei mir.

Moin B4dmin,

welcher Pfad was es in deinem Fall?

"C:\inetpub\wwwroot\aspnet_client\discover.aspx"

bei nmap gibt es bei mir das gleiche Ergebnis wie bei dir, bis auf diese Cookies hat das MS Script nichts gefunden bei mir.

hast du schon die "untergejubelte" remote shell gefunden?

Gruss Alex

Die Frage ist ja immer noch, ob bei mir was auf den Server kam oder nicht.
In keinen der Pfade die MS meldet, wurde etwas gefunden.

In dem Pfad von dir ist gar nichts drin...

Was hatte denn das Test-ProxyLogon.ps1 Script bei dir ausgegeben? Und was stand dann in der csv?

Gruß

Zitat von @B4dmin:

Die Frage ist ja immer noch, ob bei mir was auf den Server kam oder nicht.
In keinen der Pfade die MS meldet, wurde etwas gefunden.

In dem Pfad von dir ist gar nichts drin...

Du vergißt, daß bei Malware ein Fund eine hinreichende aber keine notwendige Bedingung ist.

lks

Guten Morgen zusammen,

ich habe den entsprechenden Patch am Donnerstag Abend eingespielt. (Ex2016 CU19)
Das PS Script von MS gibt mir folgendes aus:

"2021-03-03T04:44:35.102Z","c8e2096a-34b9-4825-b650-16d7d9e7e099","86.105.18.116","xxx","/ecp/y.js","X-BEResource-Cookie","ExchangeServicesClient/0.0.0.0","ServerInfo~a]@xxx:444/autodiscover/autodiscover.xml?#","200"  
"2021-03-03T07:13:15.444Z","4a3a512c-846a-4a06-bf99-9717ed437267","86.105.18.116","xxx","/ecp/y.js","X-BEResource-Cookie","ExchangeServicesClient/0.0.0.0","ServerInfo~a]@xxx:444/autodiscover/autodiscover.xml?#","200"  
"2021-03-03T10:49:15.174Z","e8f00768-72bf-4e21-8ef9-50fae84aa7fc","86.105.18.116","xxx","/ecp/y.js","X-BEResource-Cookie","ExchangeServicesClient/0.0.0.0","ServerInfo~a]@xxx:444/autodiscover/autodiscover.xml?#","200"  
"2021-03-03T21:45:16.901Z","f1bd0d66-342f-4c9a-a4b5-acb44a5349e6","139.59.56.239","xxx","/ecp/y.js","X-BEResource-Cookie","ExchangeServicesClient/0.0.0.0","ServerInfo~a]@xxx:444/autodiscover/autodiscover.xml?#","200"  

Der Microsoft Saftey Scanner rennt gerade durch. EDIT: Hat nichts gefunden.

In den ganzen von MS genannten Verzeichnissen konnte ich keine Dateien finden.

Die User berichten, dass seit heute in Outlook Meldungen wie diese auftauchen:

Bisher aber nur vereinzelt, nicht bei jedem.

Da hilft wohl nur Exchange neu machen, alle Passwörter ändern etc. Oder was meint ihr?

Grüße

Zitat von @MysticFoxDE:
Moin em-pie,

Meinen "Glückwunsch"

Spannend wäre auch mal zu wissen, wie euer Exchange bzw. der eurer Kunden installiert wurde.
Bei ins liegt der
IIS unter C:\inetpub
Die DB des Exchange auf einer weiteren VHD
Die Exchange-Installation nochmal auf einer anderen VHD
Ein %ProgramFiles%\Exchange gibt es somit bei uns nicht. Bliebe also nur das Thema mit den WebShells unter C:\inetpub, welcher bisher nichts listet, ebenso wie nichts unter %ProgramData% zu finden ist...

Moin B4dmin,

Was hatte denn das Test-ProxyLogon.ps1 Script bei dir ausgegeben? Und was stand dann in der csv?

2021-03-04T01:52:22.064Z,"6b36c41b-4ec5-42b5-a02e-ada1960a5d9f","139.162.98.150","xx.xx.xx","/ecp/y.js","X-BEResource-Cookie","ExchangeServicesClient/0.0.0.0","ServerInfo~a]@DESUL-EXCH.elsu.intern:444/autodiscover/autodiscover.xml?#","200"  
2021-03-04T01:52:28.502Z,"60cd51f0-59b6-42f3-a2d0-49e8c2bb8663","139.162.98.150","xx.xx.xx","/ecp/y.js","X-BEResource-Cookie","python-requests/2.23.0","ServerInfo~a]@DESUL-EXCH.elsu.intern:444/mapi/emsmdb/?#","200"  
2021-03-04T01:53:05.123Z,"7d77e537-4996-4b90-a402-fcdcb4170c42","139.162.98.150","xx.xx.xx","/ecp/y.js","X-BEResource-Cookie","python-requests/2.23.0","ServerInfo~a]@DESUL-EXCH.elsu.intern:444/ecp/DDI/DDIService.svc/SetObject?msExchEcpCanary=YD9J4lYzIUCZcVkYexmJf-5HcoNC4NgIvuwgeSBcEQ43ST9i1XQ03b4jtlHw7ARy_upq3JUGHUs.&schema=OABVirtualDirectory#","200"  

Gruss Alex

Ja das ist klar.

Frage was ich nun machen soll. Exchange neu aufsetzen...

Was würdet ihr denn machen?

Moin Zusammen,

unter der folgende Seite sieht man beispielhaft wie die Angreifer vorgehen.

https://www.microsoft.com/security/blog/2020/06/24/defending-exchange-se ...

Grüsse aus BaWü
Alex

Zitat von @B4dmin:

Ja das ist klar.

Frage was ich nun machen soll. Exchange neu aufsetzen...

Was würdet ihr denn machen?

Ich würde die Suche nicht auf die speziellen Pfade begrenzen, sondern schauen, ob in "ähnlichen" Pfaden auch was drin ist. Je nachdem wer wie installiert hat, hat man auch andere Pfade beim Exchange.

Ansonsten ist das wie immer eine Risikoabwägung was schlimmer ist:

"Als sauber deklarieren" mit dem Risiko, daß man doch etwas übersehen hat und dann bald voll Karacho gegen die Wand fährt (oder auch nicht).

Alles neu aufsetzen mit den Kosten und der Downtime.

Jedenfalls solltest Du auf konkrete Hinweise im Eventlog schauen, ob Versuche stattgefunden haben, Euren Exchange zu kompromittieren.

lks

Moin,

Ich glaube, mit dem Neuaufsetzen ist das gar nicht so ein riesiger Aufwand:
Frank von frankysweb hat das hier ganz gut beschrieben, wie man vorgehen kann - ohne Datenverlust:
https://www.frankysweb.de/exchange-server-neuinstallation-ohne-datenverl ...

Klar, bis Windows neu installiert und durch gepatcht ist, vergehen da schon mal gerne 2h. Dann die Exchange-Installation...

Aber wie immer ein Abwägen von Kosten und Nutzen.

Hi B4dmin,

Frage was ich nun machen soll. Exchange neu aufsetzen...

Was würdet ihr denn machen?

unabhängig vom Exchange, würde ich im Falle eines Infekts eines derart kritischen Servers, immer die Passwörter sämtlicher AD-Accounts und vor allem der, der Domänenadmins, ASAP ändern.

Die nächste wichtigste Frage ist, muss dein Exchange unbedingt weiterhin über https erreichbar sein.

Wenn nein, dann mach das Loch zu und gut ist.

Wenn ja, dann könntest du überlegen, den https Zugang noch zusätzlich per "Geofencing" zusätzlich zur WAF und AV zu schützen.
Sprich, du erlaubst den Zugriff auf die HTTPS Dienste des Exchange-Servers auch nur aus den Ländern, in denen sich die User befinden.

Grüsse aus BaWü

Alex

moin...

Zitat von @MysticFoxDE:

Hi B4dmin,

Frage was ich nun machen soll. Exchange neu aufsetzen...

Was würdet ihr denn machen?

unabhängig vom Exchange, würde ich im Falle eines Infekts eines derart kritischen Servers, immer die Passwörter sämtlicher AD-Accounts und vor allem der, der Domänenadmins, ASAP ändern.

nicht nur ändern, sondern einen neuen Administrator anlegen, und den alten stilllegen

Die nächste wichtigste Frage ist, muss dein Exchange unbedingt weiterhin über https erreichbar sein.

Wenn nein, dann mach das Loch zu und gut ist.

Wenn ja, dann könntest du überlegen, den https Zugang noch zusätzlich per "Geofencing" zusätzlich zur WAF und AV zu schützen.
Sprich, du erlaubst den Zugriff auf die HTTPS Dienste des Exchange-Servers auch nur aus den Ländern, in denen sich die User befinden.

Grüsse aus BaWü

Alex

Frank

Zitat von @B4dmin:

Ja das ist klar.

Frage was ich nun machen soll. Exchange neu aufsetzen...

Was würdet ihr denn machen?

https://www.frankysweb.de/exchange-server-neuinstallation-ohne-datenverl ...

"Ich denke ich versuche mich erstmal daran, den Exchange aus dem Veeam Backup von vor einer Woche wiederherzustellen, den Patch zu installieren und dann die Festplatte mit der aktuellen Datenbank in die neue Maschine zu übernehmen…"

halte ich noch für einen guten Workflow...

Moin Frank,

nicht nur ändern, sondern einen neuen Administrator anlegen, und den alten stilllegen

warum genau?

Gruss Alex

Zitat von @MysticFoxDE:

Moin Frank,

nicht nur ändern, sondern einen neuen Administrator anlegen, und den alten stilllegen

warum genau?

Weil man dem Admin ein paar Ostereier untergejubelt haben könnte, z.B. in seinem Profilordner.

lks

@MysticFoxDE, @B4dmin
nachstehend eine Ausgabe bei einem positven Ergebnis:

443/tcp  open  https
 http-vuln-cve2021-26855:
   VULNERABLE
   Exchange Server SSRF Vulnerability
     State: VULNERABLE
     IDs:  CVE:CVE-2021-26855

     Disclosure date: 2021-03-02
     References:
       http://aka.ms/exchangevulns

Hast du den Screenshot vor oder nach dem Patchen erstellt?

Gruß,
Dani

moin..

Zitat von @Lochkartenstanzer:

Zitat von @MysticFoxDE:

Moin Frank,

nicht nur ändern, sondern einen neuen Administrator anlegen, und den alten stilllegen

warum genau?

Weil man dem Admin ein paar Ostereier untergejubelt haben könnte, z.B. in seinem Profilordner.

lks

und weil evtl. "etwas" UID oder GID ausgeführt werden kann....

Die nächste wichtigste Frage ist, muss dein Exchange unbedingt weiterhin über https erreichbar sein.

eigentlich nicht... über VPN wäre ja auch möglich..

auf dem betroffenen Exchange, war wie ich schon oben geschrieben habe die remoteshell bereits drauf.
Diese habe ich selbstverständlich gelöscht.

das habe ich am WE auch mit einigen Exchange2019 hinter mir, 443 dichtgemacht, aber ich traue dem Braten nicht...

Frank

@LauneBaer

Die User berichten, dass seit heute in Outlook Meldungen wie diese auftauchen:

Wenn die Abfrage des Autodiscover von Outlook aus dem nichts wieder angezeigt wird, wäre mir das nicht ganz https://www.geo.de/geolino/redewendungen/3387-rtkl-redewendung-nicht-gan ... koscher]. Damit einher müsste eine Änderung gegangen sein, oder?

Bisher aber nur vereinzelt, nicht bei jedem.

Kannst du ein Schema erkennen, z.B. alle Betroffene sind Nutzer von Outlook Anywhere über das Internet?
Ist das SSL Zertifikat noch das Richtige bzw. kann es an den Clients erfolgreich geprüft und validiert werden?

Gruß,
Dani

Zitat von @Dani:

@LauneBaer

Die User berichten, dass seit heute in Outlook Meldungen wie diese auftauchen:

Ja das glaube ich auch. Wo kann ich das prüfen?

Bisher aber nur vereinzelt, nicht bei jedem.

Das Zertifikat ist noch aktuell und korrekt, das sieht soweit sauber aus.

Bin eben noch über das Skript hier gestoßen, hat das schon jemand probiert? Link

Grüße

@LauneBaer

Ja das glaube ich auch. Wo kann ich das prüfen?

Du wirst do sicher eine Doku haben, wo die Konfiguration u.a. von Autodiscover festgehalten ist?! Somit kannst du die Werte gegenprüfen und ggf. korrgieren. Wenn das nicht möglich ist, neu installieren.

Das Zertifikat ist noch aktuell und korrekt, das sieht soweit sauber aus.

Okay. Was ist mit meiner ersten Frage?!

Bin eben noch über das Skript hier gestoßen, hat das schon jemand probiert? Link

Ne, weil: CERT.LV

Gruß,
Dani

Moin Frank,

und weil evtl. "etwas" UID oder GID ausgeführt werden kann....

aber nicht ohne Authentifizierung und die Passwörter sind wie ich schon geschrieben habe alle zurückgesetzt.

Gruss Alex

Zitat von @MysticFoxDE:

Moin Frank,

und weil evtl. "etwas" UID oder GID ausgeführt werden kann....

aber nicht ohne Authentifizierung und die Passwörter sind wie ich schon geschrieben habe alle zurückgesetzt.

Aber das hindert eventuelle Ostereier und Tretminen nicht daran, im ungeeignetsten Augenblick loszugehen.

lks

Moin lks,

Aber das hindert eventuelle Ostereier und Tretminen nicht daran, im ungeeignetsten Augenblick loszugehen.

mit etwas Erfahrung lassen sich die Nester dieser Mistviecher eigentlich ganz gut ausräuchern.
Habe in den letzten Jahren leider schon diverseste Incidents betreuen dürfen und habe dabei bisher zum Glück nur bei einzelnen Servern,
die "mach alles Platt und bau wieder neu auf Keule" schwingen müssen. (Befallene Clients werden grundsätzlich immer neu installiert.)

Ich gehe im Falle eines Inzident grob immer folgend vor.
1. Gesamtes System abschotten (LAN <--> WAN vollständig trennen).
2. Absichern (Schwachstellen beseitigen, AV nachinstallieren/erneuern).
3. Definitiv befallene Systeme, je nach Schädling bereinigen oder neu aufsetzen.
4. Zugriff gezielt wieder freigeben
5. !!! FW und AV beobachten/überwachen !!!

Grüsse aus BaWü
Alex

Zitat von @Dani:

@LauneBaer

Ja das glaube ich auch. Wo kann ich das prüfen?

Sorry, habs nachgeschaut. Das sieht soweit alles korrekt aus.

Das Zertifikat ist noch aktuell und korrekt, das sieht soweit sauber aus.

Okay. Was ist mit meiner ersten Frage?!

Nein es lässt sich kein Schema erkennen. Von Logistik bis Buchhaltung, jeweils komplett andere Userrechte bzw. aktivierte Features, also querbeet.

Ich hatte vorhin mal eine Seite offen mit einem Skript, dass alle Verzeichnisse auf verdächtige aspx Dateien durchsucht. Hat den Link noch wer zur Hand? Finde es einfach nicht mehr... sorry.

Grüße

@LauneBaer

Ich hatte vorhin mal eine Seite offen mit einem Skript, dass alle Verzeichnisse auf verdächtige aspx Dateien durchsucht. Hat den Link noch wer zur Hand? Finde es einfach nicht mehr... sorry.

Erste und beste Anlaufstelle: MS CSS Exchange.

Gruß,
Dani

Zitat von @MysticFoxDE:

Moin Frank,

und weil evtl. "etwas" UID oder GID ausgeführt werden kann....

aber nicht ohne Authentifizierung und die Passwörter sind wie ich schon geschrieben habe alle zurückgesetzt.

Gruss Alex

hast ja auch recht.... ich mache das schon aus gewohnheit so... tut ja nich weh

Frank

Moin zusammen,

sind eigentllich Fälle bekannt geworden bei denen das Einfallstor Microsoft-Server-ActiveSync ist?
Den OWA gibts bei uns nur via VPN, bei ActiveSync ist ein Proxy vorgeschaltet. Logs sind sauber, aber Fragen ist immer besser.

Grüße
Stefan

Moin,

sind eigentllich Fälle bekannt geworden bei denen das Einfallstor Microsoft-Server-ActiveSync ist?

ich habe davon nicht gehört. Allerdings hat das BSI am 06.03.2021 AS in die Liste mitaufgenommen. Das werden die Tage/Wochen zeigen.

Den OWA gibts bei uns nur via VPN, bei ActiveSync ist ein Proxy vorgeschaltet. Logs sind sauber, aber Fragen ist immer besser.

Proxy ist nicht gleich Proxy. Wichtig ist, dass eine Pre-Authentifizierung stattfindet, welche nicht vom Exchange Server durchgeführt wird.

Gruß,
Dani

Moin...

mir ist eigentlich nur aufgefallen, das die meisten Exchange Server ab dem 3.3.2021 kompromittiert wurden...

Frank

Moin,

mir ist eigentlich nur aufgefallen, das die meisten Exchange Server ab dem 3.3.2021 kompromittiert wurden...

Kann ich bestätigen, oft in den frühen Morgenstunden. Was dann heißt, dass ich als Admin kaum eine Chance hatte, den Patch rechtzeitig einzuspielen...

Uns hat es scheinbar auch erwischt, da das Script "Test-ProxyLogon" anschlägt:

#TYPE Selected.System.Management.Automation.PSCustomObject
"DateTime","RequestId","ClientIpAddress","UrlHost","UrlStem","RoutingHint","UserAgent","AnchorMailbox","HttpStatus"  
"2021-03-03T04:29:56.247Z","03304c0c-b7e7-483c-b999-8a9dbbf3b121","86.105.18.116","exchange.domaene.de","/ecp/y.js","X-BEResource-Cookie","ExchangeServicesClient/0.0.0.0","ServerInfo~a]@EXCH.domaene.de:444/autodiscover/autodiscover.xml?#","200"  
"2021-03-03T06:52:47.704Z","cf47ef47-d766-42ef-a970-99dcf965757e","130.255.189.21","exchange.domaene.de","/ecp/y.js","X-BEResource-Cookie","ExchangeServicesClient/0.0.0.0","ServerInfo~a]@EXCH.domaene.de:444/autodiscover/autodiscover.xml?#","200"  
"2021-03-03T07:06:39.161Z","15443f77-3445-44bc-9f2f-1c9fd856b081","86.105.18.116","exchange.domaene.de","/ecp/y.js","X-BEResource-Cookie","ExchangeServicesClient/0.0.0.0","ServerInfo~a]@EXCH.domaene.de:444/autodiscover/autodiscover.xml?#","200"  
"2021-03-03T07:52:37.541Z","756ac685-6bbd-4467-a822-72d5e79382d6","86.105.18.116","xxx.xxx.xxx.xxx","/ecp/y.js","X-BEResource-Cookie","ExchangeServicesClient/0.0.0.0","ServerInfo~a]@EXCH.domaene.de:444/autodiscover/autodiscover.xml?#","200"  
"2021-03-03T10:43:47.192Z","c2f5b646-5fad-4f50-8cdd-f60d58d1af00","86.105.18.116","exchange.domaene.de","/ecp/y.js","X-BEResource-Cookie","ExchangeServicesClient/0.0.0.0","ServerInfo~a]@EXCH.domaene.de:444/autodiscover/autodiscover.xml?#","200"  
"2021-03-03T11:22:08.445Z","64561d4a-0753-4115-8597-1eadb43ea141","86.105.18.116","xxx.xxx.xxx.xxx","/ecp/y.js","X-BEResource-Cookie","ExchangeServicesClient/0.0.0.0","ServerInfo~a]@EXCH.domaene.de:444/autodiscover/autodiscover.xml?#","200"  
"2021-03-04T16:19:05.672Z","5124c0e6-c837-41bb-9e89-847dbfead704","103.142.141.180","exchange.domaene.de","/ecp/y.js","X-BEResource-Cookie","ExchangeServicesClient/0.0.0.0","ServerInfo~a]@EXCH.domaene.de:444/autodiscover/autodiscover.xml?#","200"  
"2021-03-04T17:28:52.355Z","bb9a67b9-2f7d-48e6-ac50-3316c1b645f3","103.142.141.180","exchange.domaene.de","/ecp/y.js","X-BEResource-Cookie","ExchangeServicesClient/0.0.0.0","ServerInfo~a]@EXCH.domaene.de:444/autodiscover/autodiscover.xml?#","200"  

Wenn ich versuche, das Skript "BackendCookieMitigation.ps1" auszuführen, erhalte ich eine Fehlermeldung:

Das kaufmännische Und-Zeichen (&) ist nicht zulässig. Der &-Operator ist für eine zukünftige Verwendung reserviert.
Verwenden Sie das kaufmännische Und-Zeichen in doppelten Anführungszeichen ("&"), um es als Teil einer Zeichenfolge zu  
übergeben.

Und noch eine Frage, ich habe diese Seite abgearbeitet, aber sonst keine Hinweise gefunden. Wäre ich aus Eurer Sicht im grünen Bereich, wenn ich die C-Partition des Exchange zurücksichere?
https://www.microsoft.com/security/blog/2021/03/02/hafnium-targeting-exc ...

Gruß

Moin,

Wenn ich versuche, das Skript "BackendCookieMitigation.ps1" auszuführen, erhalte ich eine Fehlermeldung:

Wie hast du das Script aufgerufen/gestartet? Welche Version von Exchange Server ist im Einsatz?

Gruß,
Dani

Hi Dani,

sorry, vergessen, das ist ein Exchange 2013.

Gruß

Zitat von @Coreknabe:

Uns hat es scheinbar auch erwischt, da das Script "Test-ProxyLogon" anschlägt:

> #TYPE Selected.System.Management.Automation.PSCustomObject
> "DateTime","RequestId","ClientIpAddress","UrlHost","UrlStem","RoutingHint","UserAgent","AnchorMailbox","HttpStatus"  
> "2021-03-03T04:29:56.247Z","03304c0c-b7e7-483c-b999-8a9dbbf3b121","86.105.18.116","exchange.domaene.de","/ecp/y.js","X-BEResource-Cookie","ExchangeServicesClient/0.0.0.0","ServerInfo~a]@EXCH.domaene.de:444/autodiscover/autodiscover.xml?#","200"  
> "2021-03-03T06:52:47.704Z","cf47ef47-d766-42ef-a970-99dcf965757e","130.255.189.21","exchange.domaene.de","/ecp/y.js","X-BEResource-Cookie","ExchangeServicesClient/0.0.0.0","ServerInfo~a]@EXCH.domaene.de:444/autodiscover/autodiscover.xml?#","200"  
> "2021-03-03T07:06:39.161Z","15443f77-3445-44bc-9f2f-1c9fd856b081","86.105.18.116","exchange.domaene.de","/ecp/y.js","X-BEResource-Cookie","ExchangeServicesClient/0.0.0.0","ServerInfo~a]@EXCH.domaene.de:444/autodiscover/autodiscover.xml?#","200"  
> "2021-03-03T07:52:37.541Z","756ac685-6bbd-4467-a822-72d5e79382d6","86.105.18.116","xxx.xxx.xxx.xxx","/ecp/y.js","X-BEResource-Cookie","ExchangeServicesClient/0.0.0.0","ServerInfo~a]@EXCH.domaene.de:444/autodiscover/autodiscover.xml?#","200"  
> "2021-03-03T10:43:47.192Z","c2f5b646-5fad-4f50-8cdd-f60d58d1af00","86.105.18.116","exchange.domaene.de","/ecp/y.js","X-BEResource-Cookie","ExchangeServicesClient/0.0.0.0","ServerInfo~a]@EXCH.domaene.de:444/autodiscover/autodiscover.xml?#","200"  
> "2021-03-03T11:22:08.445Z","64561d4a-0753-4115-8597-1eadb43ea141","86.105.18.116","xxx.xxx.xxx.xxx","/ecp/y.js","X-BEResource-Cookie","ExchangeServicesClient/0.0.0.0","ServerInfo~a]@EXCH.domaene.de:444/autodiscover/autodiscover.xml?#","200"  
> "2021-03-04T16:19:05.672Z","5124c0e6-c837-41bb-9e89-847dbfead704","103.142.141.180","exchange.domaene.de","/ecp/y.js","X-BEResource-Cookie","ExchangeServicesClient/0.0.0.0","ServerInfo~a]@EXCH.domaene.de:444/autodiscover/autodiscover.xml?#","200"  
> "2021-03-04T17:28:52.355Z","bb9a67b9-2f7d-48e6-ac50-3316c1b645f3","103.142.141.180","exchange.domaene.de","/ecp/y.js","X-BEResource-Cookie","ExchangeServicesClient/0.0.0.0","ServerInfo~a]@EXCH.domaene.de:444/autodiscover/autodiscover.xml?#","200"  
> 

Bei dir ist wohl exakt das gleiche wie bei uns passiert. Auch die IP 86.105.18.116 ist gleich.

Wenn ich versuche, das Skript "BackendCookieMitigation.ps1" auszuführen, erhalte ich eine Fehlermeldung:

> Das kaufmännische Und-Zeichen (&) ist nicht zulässig. Der &-Operator ist für eine zukünftige Verwendung reserviert.
> Verwenden Sie das kaufmännische Und-Zeichen in doppelten Anführungszeichen ("&"), um es als Teil einer Zeichenfolge zu  
> übergeben.
> 

Ist das Skript nur notwendig wenn man den Patch noch nicht drauf hat?

Das würde mich auch interessieren. Wir haben die Exchange Datenbanken auf einer eigenen VHDX (D: ). Reicht es da einfach die alte VHDX der C: Partition zu restoren oder kommt er damit nicht klar?

Gruß

Grüße

Zitat von @LauneBaer:

Zitat von @Coreknabe:

Uns hat es scheinbar auch erwischt, da das Script "Test-ProxyLogon" anschlägt:

>> #TYPE Selected.System.Management.Automation.PSCustomObject
>> "DateTime","RequestId","ClientIpAddress","UrlHost","UrlStem","RoutingHint","UserAgent","AnchorMailbox","HttpStatus"  
>> "2021-03-03T04:29:56.247Z","03304c0c-b7e7-483c-b999-8a9dbbf3b121","86.105.18.116","exchange.domaene.de","/ecp/y.js","X-BEResource-Cookie","ExchangeServicesClient/0.0.0.0","ServerInfo~a]@EXCH.domaene.de:444/autodiscover/autodiscover.xml?#","200"  
>> "2021-03-03T06:52:47.704Z","cf47ef47-d766-42ef-a970-99dcf965757e","130.255.189.21","exchange.domaene.de","/ecp/y.js","X-BEResource-Cookie","ExchangeServicesClient/0.0.0.0","ServerInfo~a]@EXCH.domaene.de:444/autodiscover/autodiscover.xml?#","200"  
>> "2021-03-03T07:06:39.161Z","15443f77-3445-44bc-9f2f-1c9fd856b081","86.105.18.116","exchange.domaene.de","/ecp/y.js","X-BEResource-Cookie","ExchangeServicesClient/0.0.0.0","ServerInfo~a]@EXCH.domaene.de:444/autodiscover/autodiscover.xml?#","200"  
>> "2021-03-03T07:52:37.541Z","756ac685-6bbd-4467-a822-72d5e79382d6","86.105.18.116","xxx.xxx.xxx.xxx","/ecp/y.js","X-BEResource-Cookie","ExchangeServicesClient/0.0.0.0","ServerInfo~a]@EXCH.domaene.de:444/autodiscover/autodiscover.xml?#","200"  
>> "2021-03-03T10:43:47.192Z","c2f5b646-5fad-4f50-8cdd-f60d58d1af00","86.105.18.116","exchange.domaene.de","/ecp/y.js","X-BEResource-Cookie","ExchangeServicesClient/0.0.0.0","ServerInfo~a]@EXCH.domaene.de:444/autodiscover/autodiscover.xml?#","200"  
>> "2021-03-03T11:22:08.445Z","64561d4a-0753-4115-8597-1eadb43ea141","86.105.18.116","xxx.xxx.xxx.xxx","/ecp/y.js","X-BEResource-Cookie","ExchangeServicesClient/0.0.0.0","ServerInfo~a]@EXCH.domaene.de:444/autodiscover/autodiscover.xml?#","200"  
>> "2021-03-04T16:19:05.672Z","5124c0e6-c837-41bb-9e89-847dbfead704","103.142.141.180","exchange.domaene.de","/ecp/y.js","X-BEResource-Cookie","ExchangeServicesClient/0.0.0.0","ServerInfo~a]@EXCH.domaene.de:444/autodiscover/autodiscover.xml?#","200"  
>> "2021-03-04T17:28:52.355Z","bb9a67b9-2f7d-48e6-ac50-3316c1b645f3","103.142.141.180","exchange.domaene.de","/ecp/y.js","X-BEResource-Cookie","ExchangeServicesClient/0.0.0.0","ServerInfo~a]@EXCH.domaene.de:444/autodiscover/autodiscover.xml?#","200"  
>> 

Bei dir ist wohl exakt das gleiche wie bei uns passiert. Auch die IP 86.105.18.116 ist gleich.

die IP 86.105.18.116 taucht überall auf...

Wenn ich versuche, das Skript "BackendCookieMitigation.ps1" auszuführen, erhalte ich eine Fehlermeldung:

>> Das kaufmännische Und-Zeichen (&) ist nicht zulässig. Der &-Operator ist für eine zukünftige Verwendung reserviert.
>> Verwenden Sie das kaufmännische Und-Zeichen in doppelten Anführungszeichen ("&"), um es als Teil einer Zeichenfolge zu  
>> übergeben.
>> 

Ist das Skript nur notwendig wenn man den Patch noch nicht drauf hat?

hmmmpf... also wenn du ein Backup hast, von vor der Infektion, sag ich mal ja... bitte nach dem restore als erstes testen, und dann aktualsieren!

Das würde mich auch interessieren. Wir haben die Exchange Datenbanken auf einer eigenen VHDX (D: ). Reicht es da einfach die alte VHDX der C: Partition zu restoren oder kommt er damit nicht klar?

im grunde geht das...

Gruß

Grüße

Frank

@Coreknabe
Was ist mit meiner ersten Frage?

moin...

Zitat von @Dani:

Was ist mit meiner ersten Frage?

Sorry, habe ich was übersehen, welche Frage?

Frank

Sorry Frank! Mein Fehler, Usernamen vergessen.

@LauneBaer

Ist das Skript nur notwendig wenn man den Patch noch nicht drauf hat?

Das hat mit dem Patch an sich nix zu tun, das ist eben der Test, ob was passiert sein könnte.

@Frank
Danke!

@Dani
Du hattest gefragt, welche Exchange-Version, habe ich oben beantwortet, ist 2013. Oder war ich jetzt gar nicht gemeint?
*kopfkratz*

@Coreknabe

Wenn ich versuche, das Skript "BackendCookieMitigation.ps1" auszuführen, erhalte ich eine Fehlermeldung:

Wie hast du das Script aufgerufen/gestartet?

Darum geht bzw. ging es mir.

Lesekompetenz und ich... Sorry, hatte ich überlesen.

Ich kopiere das Skript lokal auf den Exchange und führe es dann in der Powershell mit Admin-Rechten so aus:

.\BackendCookieMitigation.ps1 -WebSiteNames "Default Web Site" -Verbose

Moin,
sieht soweit korrekt aus. Woher kommt dann der & Operator? *grübel* Da wir es gerade von Lesen haben... Der Aufruf funktioniert meiner Meinung nach nur, wenn das IIS URL Rewrite module bereits installiert ist. Ist das bei dir so?

Gruß,
Dani

OK, danke.

Leicht missverständlich, auf der Seite heißt es:

To apply without MSI install
PS C:\> BackendCookieMitigation.ps1 -WebSiteNames "Default Web Site" -Verbose

Habe jetzt mal das URL Rewrite Module installiert, bekomme aber dieselbe Fehlermeldung.

EDIT: Wenn ich das Rewrite Module in denselben Ordner kopiere und darauf verweise, klappt es ebenfalls nicht, Fehlermeldung wie oben.
Also

.\BackendCookieMitigation.ps1 -FullPathToMSI "D:\HAFNIUM\rewrite_x64_de-DE" -WebSiteNames "Default Web Site" -Verbose  

Moin,

Habe jetzt mal das URL Rewrite Module installiert, bekomme aber dieselbe Fehlermeldung.

Ich hab grad kein Zugang auf eine Test Umgebung. Praktische Erfahrung habe ich leider auch nicht, da wir nicht betroffen waren.

Was geschieht wenn du den Aufruf mit dem Paramter für das URL Rewrite module trotzdem angibst.

Gruß,
Dani

Was geschieht wenn du den Aufruf mit dem Paramter für das URL Rewrite module trotzdem angibst.

Habe die Info gerade noch angehängt, selbe Fehlermeldung...

Hallo zusammen,

gestern 2 Exchange Server 2019 auf 1.3. zurückgesichert (Die Attacken waren am 2.3. um 7h morgens...). Durchaus lästig, aber wenigstens klappen die Backups.

Heute meldet sich ein Neukunde (völlig unbekannte Konfiguration, aber uralter xchange 2016 CU7...), der hat nur 2 Zeilen in dem Test-ProxyLogon.ps1 und beide mit HTTP Code 500

Jetzt ist die Frage: 500 = not authenticated, muss überhaupt zurückgesichert werden?
Mein erster Eindruck wäre: Nein, der Angriff wurde zwar versucht, war aber nicht erfolgreich.

Ich habe auf den anderen Servern (nach Restore + Patch) bisher keine Einträge mehr, allerdings ist das natürlich nicht aussagekräftig.
Was würdet ihr sagen?
Restore oder einfach "nur" CU-Update + Patches drauf?
Konnte darüber leider im Netz nichts finden.

Schöne Grüße aus dem Süden,
Drohnald

moin...

Zitat von @Drohnald:

Hallo zusammen,

gestern 2 Exchange Server 2019 auf 1.3. zurückgesichert (Die Attacken waren am 2.3. um 7h morgens...). Durchaus lästig, aber wenigstens klappen die Backups.

oh... es gab sie doch vor dem 03.03.2021

hast du nach dem Restore mal noch mal

detect_webshells.ps1

und

Test-ProxyLogon.ps1

ausgeführt?

Heute meldet sich ein Neukunde (völlig unbekannte Konfiguration, aber uralter xchange 2016 CU7...), der hat nur 2 Zeilen in dem Test-ProxyLogon.ps1 und beide mit HTTP Code 500

hm..

Jetzt ist die Frage: 500 = not authenticated, muss überhaupt zurückgesichert werden?
Mein erster Eindruck wäre: Nein, der Angriff wurde zwar versucht, war aber nicht erfolgreich.

würde ich auch sagen... obiges laufen lassen?

Ich habe auf den anderen Servern (nach Restore + Patch) bisher keine Einträge mehr, allerdings ist das natürlich nicht aussagekräftig.

schwer zu sagen...

Was würdet ihr sagen?
Restore oder einfach "nur" CU-Update + Patches drauf?

wenn möglich restore mit Test, dann CU und Patch.. und naoch mal Test...
oder ein Exchange RecoverServer Setup... dauert genauso lange, wäre aber sicher..

Konnte darüber leider im Netz nichts finden.

Schöne Grüße aus dem Süden,
Drohnald

Frank

Moin Dani,

Der Aufruf funktioniert meiner Meinung nach nur, wenn das IIS URL Rewrite module bereits installiert ist. Ist das bei dir so?

das ist richtig und es funktioniert auch nur korrekt mit dem englischsprachigem IIS URL Rewrite Module.

Grüsse aus BaWü
Alex

Hi Alex,

das ist richtig und es funktioniert auch nur korrekt mit dem englischsprachigem IIS URL Rewrite Module.

Das stimmt so nicht. Siehe
https://msrc-blog.microsoft.com/2021/03/05/microsoft-exchange-server-vul ...

Dort heißt es u.a.:
PowerShell command to create IIS rewrite rule without installing the IIS rewrite module:
.\BackendCooieMitigation.ps1 -WebSiteNames "Default Web Site" -Verbose

Habe es auch mit dem englischsprachigen Rewrite Module versucht, bekomme immer noch dieselbe Fehlermeldung. Auch ist es egal, ob ich es installiert habe oder nur auf den Pfad verweise.

Gruß

EDIT: Schon wieder Lesekompetenz meinerseits

Du hattest nichts geschrieben, dass das Rewrite Module installiert sein muss. Wie auch immer, ich kann das Skript nicht starten. Mit dem Skript "detect_webshells.ps1" bekomme ich dieselbe Fehlermeldung...

Moin Coreknabe,

bei mir hat das Skript am Anfang auch ganz schön rumgezickt, aber wie heisst es so schön, Augen zu und durch. 😁

Bei mir lief das ganze mit dem folgenden Aufruf.

.\BackendCookieMitigation.ps1 -FullPathToMSI "C:\temp\rewrite_amd64_en-US.msi" -WebSiteNames "Default Web Site" -Verbose  

(die BackendCookieMitigation.ps1 & rewrite_amd64_en-US.msi lagen bei mir unter C:\Temp)

Bitte darauf achten, dass du die richtige Version (rewrite_amd64_en-US.msi) herunterlädst.

Wenn du die Rewrite Module schon vorher installiert hast, dann deinstalliere die bereits installierte Version und boote den Server nach der Deinstallation, vor dem ausführen des oberen Befehls, sicherheitshalber einmal durch.

Grüsse aus BaWü
Alex

P.S. kann es vielleicht sein, dass bei dir im IIS die "Default Web Site" umbenannt ist?

Hi Alex,

danke für die Unterstützung.

Scheinbar war die heruntergeladene Datei nicht OK. Ich habe mir die backendcookiemitigation noch einmal heruntergeladen, jetzt komme ich zumindest etwas weiter.
Bei mir heißt die Version rewrite_2.0_rtw_x64.msi, ist für meine Begriffe auch die richtige.

Starte ich nun das Skript mit Verweis auf die msi, endet der Versuch mit der Meldung

[ERROR] Unable to proceed on EXCHANGE, path to IIS URL Rewrite Module MSI  not provided and module is not installed.

detect_webshells.ps1 habe ebenfalls erneut heruntergeladen, funktioniert jetzt und wirft dies aus:

No webshells found, but they might have been removed or attackers might have used other persistence techniques

Gruß

dir ist aber bekannt, das der Rewrite nur dafür gut ist, wenn du das System aus einem Grund nicht patchen kannst?

Wenn das System befallen war, kann es de facto jederzeit wieder zu einem Ausbruch kommen, praktisch kannst du damit jeden Tag aufs neue Scannen und hoffen, dass es nicht auf andere Systeme eskaliert.

Hi,

jein. Die per Webshell aufgerufenen URLs werden umgeleitet. Ob sich das System patchen lässt, oder nicht, hat damit nichts zu tun. Du musst halt nur das Glück haben, dass das Skript die maliziösen URLs kennt und damit berücksichtigt.

Wenn das System befallen war, kann es de facto jederzeit wieder zu einem Ausbruch kommen, praktisch kannst du damit jeden Tag aufs neue Scannen und hoffen, dass es nicht auf andere Systeme eskaliert.

Das Scannen wird nichts mehr nützen, es gilt, mögliche Webshells zu finden, die abgelegt wurden. Selbst wenn der Scanner nichts findet, heißt das aber nichts. Das sagt auch das Skript detect_webshells.ps1 bei "Erfolg":

No webshells found, but they might have been removed or attackers might have used other persistence techniques

Und eben das ist das Problem, die Webshell könnte abgelegt und wieder entfernt worden sein, nachdem eine Tür geöffnet wurde. Meine Hoffnung ist, dass die Angreifer nicht alle Lücken sofort ausnützen können, weil ab einem bestimmten Punkt bei aller Automatisierung Handarbeit erforderlich sein könnte. Bei der Vielzahl der betroffenen Systeme können die Angreifer nicht sofort alles verwerten. Mag mich in dem Punkt aber auch täuschen.

Ich habe heute noch einmal einen Termin mit einem Unternehmen, das sich mit IT-Sicherheit beschäftigt. Danach werde ich entscheiden, wie ich weiter verfahre. Bereits jetzt habe ich die Erreichbarkeit des Mailservers auf eine deutsche IP beschränkt, hilft vielleicht etwas. Ansonsten konnte ich bisher außer weiteren Angriffsversuchen, die nach Einspielen des Patches scheitern, keine Anzeichen für ungewöhnliche Aktivitäten feststellen können. Muss aber auch nichts heißen, da ich in dem Bereich kein Profi bin.
Wahrscheinlich werde ich entweder die C-Partition aus einem sauberen Backup wiederherstellen (und hoffen, dass der Exchange und das AD das so schlucken, da Sicherung vom 28.02.2021) oder mit dieser Anleitung den Exchange säubern:
https://www.frankysweb.de/exchange-server-neuinstallation-ohne-datenverl ...

Gruß

Unser Server scheint nun wieder "sauber" zu sein. Wir haben eine Nachtschicht eingelegt und das System komplett neu aufgesetzt bzw. die C:\ Partition und danach die andere Partition mit der Datenbank wieder gemountet.

Die anderen Server haben wir ebenfalls überprüft aber keine verdächtigte Aktionen feststellen können.

Ich konnte sehen, dass unser System ab dem 03.03.2021 um 6:49 komromittiert wurde. Unserer Sicherung ging leider nur bis zum 03.03 zurück. Allerdings wurde dort Abends gesichert. Zukünftig werde ich nun noch Monats und Quartals Sicherungen auf zwei spiegelnden NAS Systemen vorhalten...

ProxyLogon Status: Exchange Server EXCHANGE
  [CVE-2021-26855] Suspicious activity found in Http Proxy log!

DateTime                 AnchorMailbox
--------                 -------------
2021-03-03T05:06:49.716Z ServerInfo~a]@exchange.firma.local:444/autodiscover/autodiscover.xml?#


  [CVE-2021-27065] Suspicious activity found in ECP logs!
  Please review the following files for 'Set-*VirtualDirectory' entries:  
   C:\Program Files\Microsoft\Exchange Server\V15\Logging\ECP\Server\ECPServer20210303-1.LOG
   C:\Program Files\Microsoft\Exchange Server\V15\Logging\ECP\Server\ECPServer20210305-1.LOG
   C:\Program Files\Microsoft\Exchange Server\V15\Logging\ECP\Server\ECPServer20210306-1.LOG
   C:\Program Files\Microsoft\Exchange Server\V15\Logging\ECP\Server\ECPServer20210307-1.LOG

Ob Daten abgeflossen sind kann ich nun noch nicht bestätigen.

moin

Zitat von @ingrimmsch:

Unser Server scheint nun wieder "sauber" zu sein. Wir haben eine Nachtschicht eingelegt und das System komplett neu aufgesetzt bzw. die C:\ Partition und danach die andere Partition mit der Datenbank wieder gemountet.

Die anderen Server haben wir ebenfalls überprüft aber keine verdächtigte Aktionen feststellen können.

Ich konnte sehen, dass unser System ab dem 03.03.2021 um 6:49 komromittiert wurde. Unserer Sicherung ging leider nur bis zum 03.03 zurück. Allerdings wurde dort Abends gesichert. Zukünftig werde ich nun noch Monats und Quartals Sicherungen auf zwei spiegelnden NAS Systemen vorhalten...

ProxyLogon Status: Exchange Server EXCHANGE
>   [CVE-2021-26855] Suspicious activity found in Http Proxy log!
> 
> DateTime                 AnchorMailbox
> --------                 -------------
> 2021-03-03T05:06:49.716Z ServerInfo~a]@exchange.firma.local:444/autodiscover/autodiscover.xml?#
> 
> 
>   [CVE-2021-27065] Suspicious activity found in ECP logs!
>   Please review the following files for 'Set-*VirtualDirectory' entries:  
>    C:\Program Files\Microsoft\Exchange Server\V15\Logging\ECP\Server\ECPServer20210303-1.LOG
>    C:\Program Files\Microsoft\Exchange Server\V15\Logging\ECP\Server\ECPServer20210305-1.LOG
>    C:\Program Files\Microsoft\Exchange Server\V15\Logging\ECP\Server\ECPServer20210306-1.LOG
>    C:\Program Files\Microsoft\Exchange Server\V15\Logging\ECP\Server\ECPServer20210307-1.LOG

Ob Daten abgeflossen sind kann ich nun noch nicht bestätigen.

ich denke, das wird auch kaum möglich sein...

Frank

Hallo,

ich überlege auch gerade heute Nacht die Kiste aus einem Backup wiederherzustellen. Da Exchange jetzt nicht mein Kernthema ist und unser Systemhaus überraschenderweise keine Zeit hat würde ich das gerne wie folgt machen:

- In der Firewall alle Ports Exchange betreffend schließen, damit keine Mails mehr ankommen
- VM runterfahren und beide VHDX Dateien (C und D) wegsichern (man weiß ja nie)
- Die VHDX von Laufwerk C aus dem Backup holen (02.03.) und Offline ohne Netzwerk starten
- CU19 und den Patch installieren
- Checken ob alle Dienste sauber laufen und die Verbindung mit einem lokalen Outlook testen
- Firewall wieder öffnen und hoffen, dass alles geklappt hat

Wäre das ein gängiger Weg bzw. funktioniert das überhaupt? (Thema AD usw.)

Danke und viele Grüße

Zitat von @LauneBaer:

Moin...

wiso haben die keine Zeit?

- In der Firewall alle Ports Exchange betreffend schließen, damit keine Mails mehr ankommen

jo.. port 443 nicht vergessen... am besten jetzt schon dicht machen!

- VM runterfahren und beide VHDX Dateien (C und D) wegsichern (man weiß ja nie)

ok.. gut

- Die VHDX von Laufwerk C aus dem Backup holen (02.03.) und Offline ohne Netzwerk starten

das muss nicht offline sein...cdfas geht auch Online...

- CU19 und den Patch installieren

jo..

- Checken ob alle Dienste sauber laufen und die Verbindung mit einem lokalen Outlook testen
- Firewall wieder öffnen und hoffen, dass alles geklappt hat

Wäre das ein gängiger Weg bzw. funktioniert das überhaupt? (Thema AD usw.)

ja.. geht

Danke und viele Grüße

Frank

Zitat von @Vision2015:

wiso haben die keine Zeit?

Ich vermute Mal, weil die mehr als einen Exhange verkackt haben und daher keine Zeit haben.

lks

Zitat von @Lochkartenstanzer:

Zitat von @Vision2015:
wiso haben die keine Zeit?

Ich vermute Mal, weil die mehr als einen Exhange verkackt haben und daher keine Zeit haben.

Eher weil ganz viele Einmal-Kunden anrufen die sich nach dem Kauf gegen einen Wartungs-Vertrag entschieden haben oder schlicht ganz neue Kunden wo irgendwer irgendwann den Exchange mal installiert hat. Bei beiden Gruppen hat seit 2 Jahren Niemand irgendwelche Updates an Server und Firewall gemacht und nun muss es natürlich ganz schnell gehen....

PS: Ich hatte heute auch so einen am Telefon.
Exchange 2013 CU9
Als ich grob den Aufwand skizziert habe hies es dann, dass die sich wieder melden...
Haben sie aber noch nicht.

moin...
moin...

Zitat von @StefanKittel:

Zitat von @Lochkartenstanzer:

Zitat von @Vision2015:
wiso haben die keine Zeit?

Ich vermute Mal, weil die mehr als einen Exhange verkackt haben und daher keine Zeit haben.

hm... jo bei uns brennt auch die Bude, wir sind mit 5 Mann beschäftigt, nur Exchange Gurken zu Fixen... klar ist das hart, aber sowas lässt doch keiner liegen.... wir nehmen jedenfalls noch an

Frank

Moin lks,

Ich vermute Mal, weil die mehr als einen Exhange verkackt haben und daher keine Zeit haben.

eigentlich hat Microsoft dieses Exchange Problem verursacht und somit hauptsächlich verkackt und nicht das angesprochene Systemhaus. 😉

Gruss Alex

Zitat von @MysticFoxDE:

eigentlich hat Microsoft dieses Exchange Problem verursacht und somit hauptsächlich verkackt und nicht das angesprochene Systemhaus. 😉

Ursprünglich hat MS diese Problem verursacht. Aber ein Systemhaus muß Vorkehrungen treffen, daß sowas nicht allzu heftig druchschlägt.

Was ich sagen wollte, daß aktuelle alle Systemhäuser vermutlich alle Hönde voll zu tun haben Ihre Installationen zu prüfen, bzw den Notrufen Ihre alten udn neuen Kunden zu folgen.

lks

Hi LauneBaer,

ich habe heute die C-Partition aus einem sauberen Backup wiederhergestellt (Backup vom 28.02.). Im HyperV einfach die wiederhergestellte C-Partition statt der korrumpierten Version eingebunden, funktionierte alles wunderbar.
Für den OWA-Zugriff habe ich in der Firewall noch GeoIP dahingehend konfiguriert, dass nur deutsche IP-Adressen Zugriff haben. Sicher keine schusssichere Variante, hält aber wohl das eine oder andere ab.
Ansonsten wird das so funktionieren, wie Du schreibst.

Gruß und viel Erfolg!

Moin Zusammen,

hier wurde schon öfters die Frage gestellt, über welche Exchange WebDienste (OWA, ECP, OAB, ...) dieser Angrifft theoretisch erfolgen könnte. Laut dem BSI die folgenden.

"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."

😬😱🤢

Siehe Link für weitere Informationen.
https://www.bsi.bund.de/SharedDocs/Cybersicherheitswarnungen/DE/2021/202 ...

Grüsse aus BaWü
Alex

P.S. !!! Die Bedrohungslage ist auf der höchsten Stufe (4/Rot) !!!
"Die IT-Bedrohungslage ist extrem kritisch. Ausfall vieler Dienste, der Regelbetrieb kann nicht aufrecht erhalten werden"

Zitat von @MysticFoxDE:

P.S. !!! Die Bedrohungslage ist auf der höchsten Stufe (4/Rot) !!!
"Die IT-Bedrohungslage ist extrem kritisch. Ausfall vieler Dienste, der Regelbetrieb kann nicht aufrecht erhalten werden"

Naja, mit amerikanischen Monokulturen war das schon immer so, daß dann alles auf einmal befallen wird. Da hilft auch kein Glyphosat.

lks

Moin Zusammen,

es gibt mittlerweile von Microsoft ein erweitertes Prüfskript.

https://github.com/dpaulson45/HealthChecker

Grüsse aus BaWü
Alex

Zitat von @Coreknabe:

Hi LauneBaer,

ich habe heute die C-Partition aus einem sauberen Backup wiederhergestellt (Backup vom 28.02.). Im HyperV einfach die wiederhergestellte C-Partition statt der korrumpierten Version eingebunden, funktionierte alles wunderbar.
Für den OWA-Zugriff habe ich in der Firewall noch GeoIP dahingehend konfiguriert, dass nur deutsche IP-Adressen Zugriff haben. Sicher keine schusssichere Variante, hält aber wohl das eine oder andere ab.
Ansonsten wird das so funktionieren, wie Du schreibst.

Gruß und viel Erfolg!

Hi,

danke, ich hab es exakt auch so gestern Abend gemacht und hat auch gut funktioniert. Ebenso den Geoblock habe ich eingestellt, wobei ich mir davon auch nicht viel erhoffe, aber schadet ja nicht.
Ich musste dann noch feststellen, dass das ECP in Exchange 2016 standardmäßig von außen erreichbar ist. Das habe ich dann inkl. OWA auch gleich noch deaktiviert. Link

Sämtliche Prüfskripte und auch der neue Healthcheck laufen bei mir jetzt fehlerfrei durch. Passwörter wurden sicherheitshalber auch von allen Usern geändert.

Noch eine Frage an die Experten: Lässt sich denn der Zugriff von außen via ActiveSync irgendwie besser schützen? Oder bleibt da nur der Weg, dass es nur noch per VPN geht und nach extern komplett dicht machen?

Danke und Grüße

Moin,

Zitat von @LauneBaer:
Ich musste dann noch feststellen, dass das ECP in Exchange 2016 standardmäßig von außen erreichbar ist. Das habe ich dann inkl. OWA auch gleich noch deaktiviert. Link

Das hätte ich eher so gelöst:
https://www.frankysweb.de/exchange-2016-eac-nur-im-internen-netzwerk-fre ...

Dann kommst du von intern noch an das ecp - jedoch über einen anderen Port, z.B. 55443, welcher aber an der FW von Außen blockiert wird...
Ist natürlich hinfällig, wenn ihr ohnehin alles per Powershell löst.

Gruß
em-pie

Moin,

Noch eine Frage an die Experten: Lässt sich denn der Zugriff von außen via ActiveSync irgendwie besser schützen? Oder bleibt da nur der Weg, dass es nur noch per VPN geht und nach extern komplett dicht machen?

Ja, wir schützen unsere Instanzen OWA, ECP, etc... mit Hilfe von AD FS, WAP und WAF. Bis dato keinerlei Probleme inkl. dem 0day Exploit. Wir haben ruhig geschlafen.

Vergleicht man allerdings die Kosten für Einrichtung, Unterhalt so ist die VPN Variante bis zu einer bestimmten Größe wirtschaftlicher und einfacher um zu setzen.

Gruß,
Dani

Zitat von @em-pie:
Spannend wäre auch mal zu wissen, wie euer Exchange bzw. der eurer Kunden installiert wurde.
Bei ins liegt der
IIS unter C:\inetpub
Die DB des Exchange auf einer weiteren VHD
Die Exchange-Installation nochmal auf einer anderen VHD
Ein %ProgramFiles%\Exchange gibt es somit bei uns nicht. Bliebe also nur das Thema mit den WebShells unter C:\inetpub, welcher bisher nichts listet, ebenso wie nichts unter %ProgramData% zu finden ist...

Mal eine weitere Frage in die Runde:
Bei denen es bisweilen keine Anzeichen auf ein kompromittiertes System gibt:
Dürfen eure Exchange-Server (bzw. die eurer Kunden) von sich aus ins eine Verbindung ins WAN aufbauen (SMTP mal abgesehen) oder ist das unterbunden?
Bzw. umgekehrt: Bei den Systemen, denen ein Angriff widerfahren ist: Haben eure Systeme "freies Geleit" ins WWW?

Unsere Kiste kann keinerlei Seiten, etc. aus dem WAN aufrufen. Lediglich SMTP-Traffic wird nach außen (bzw. zum internen Mail-Relay an der FW) geleitet. Alles andere ist untersagt. Somit wäre es tendenziell deutlich schwieriger, Schadcode aus dem WAN nachzuladen.

Wobei eine Webshell ja andersherum betrachtet darauf abzielt, dass sich jemand von außen verbindet und über diesen Weg Code einfügen müsste bzw. Daten über diese Session hochladen muss.

Generell geht der komplette Traffic durch WAF (eingehend) und Webfilter (ausgehend) plus SMTP über Emailproxy.

Wenn nicht komplett verbarrikadiert halten wir das für sinnvollste Option. Wir sind uns auch noch unschlüssig, ob das nicht erst die erste Welle war, was, wenn im Portfolio noch Android und iOS Hacks lagern...eine VPN wird dann auch nutzlos, im Zweifel trügerisch sicher. Wobei eine VPN für puren Emailabruf auch suboptimal scheint. Wie löst Ihr das?

Moin...

Generell geht der komplette Traffic durch WAF (eingehend) und Webfilter (ausgehend) plus SMTP über Emailproxy.

hat leider nicht jeder Kunde.... halte ich aber auch für den besten weg

Wir sind uns auch noch unschlüssig, ob das nicht erst die erste Welle war, was, wenn im Portfolio noch Android und iOS Hacks lagern....

ich bin mir fast sicher, das es nur die erste welle war... dafür war das zu einfach!

Frank

Aufklärungsarbeit, bringt natürlich auch Anforderungen in der Hinsicht, dass die WAF auch bekannt ist und eingesetzt wird, Hier schliesst sich die Parabel.

Gut, dass wir uns beim Rest einig sind.

Zitat von @Vision2015:

Moin...

Generell geht der komplette Traffic durch WAF (eingehend) und Webfilter (ausgehend) plus SMTP über Emailproxy.

hat leider nicht jeder Kunde.... halte ich aber auch für den besten weg

Ich glaube nicht, daß WAF immer der beste Weg ist.

duck und wech

lks

Kommst du gerade aus dem Forum der Grünen?

Wenn wir von PoC sprachen ist das auch kein people of colo(u)r, sondern ein Meilenstein im Projekt...(Hautfarbenunabhängig)

Moin,

Dürfen eure Exchange-Server (bzw. die eurer Kunden) von sich aus ins eine Verbindung ins WAN aufbauen (SMTP mal abgesehen) oder ist das unterbunden?

Grundsätzlich verfolgen wir den Ansatz Outbound Firewalling. Egal um welche Systeme und Art es geht. Exchange Server selbst sind hinter SMTP Proxies (kein SMTP Relay) versteckt. Ansonsten sind keine weiteren Ports nach außen freigegeben. Für OWA, ECP, AS, MAPI, etc... nutzen wir vorgelagerte Systeme, die auch die Authentifizierung durchführen. Eine WAF ist das i-Tüpfelchen.

Gruß,
Dani

Für OWA, ECP, AS, MAPI, etc... nutzen wir vorgelagerte Systeme, die auch die Authentifizierung durchführen.

Hi Dani,

autodiscover läuft aber nur ohne Authentifizierung.
Oder irre ich mich?
MfG heilgecht