Exchange Zero Day Hack - Wie entfernen?

Mitglied: mtaiit

mtaiit (Level 1) - Jetzt verbinden

07.03.2021 um 09:50 Uhr, 8264 Aufrufe, 109 Kommentare, 5 Danke

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
109 Antworten
Mitglied: 147669
147669 (Level 1)
LÖSUNG 07.03.2021, aktualisiert um 10:18 Uhr
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
Bitte warten ..
Mitglied: Lochkartenstanzer
07.03.2021 um 10:45 Uhr
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
Bitte warten ..
Mitglied: Th0mKa
LÖSUNG 07.03.2021 um 10:53 Uhr
Zitat von @mtaiit:
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
Bitte warten ..
Mitglied: mtaiit
07.03.2021 um 10:58 Uhr
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?
Bitte warten ..
Mitglied: MysticFoxDE
07.03.2021 um 11:02 Uhr
Moin,

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



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

Grüsse aus BaWü
Alex
Bitte warten ..
Mitglied: MysticFoxDE
07.03.2021 um 11:07 Uhr
Unter dem folgenden Link gibt es auch noch wichtige Hinweise.

https://msrc-blog.microsoft.com/2021/03/05/microsoft-exchange-server-vul ...
Bitte warten ..
Mitglied: mtaiit
07.03.2021 um 12:46 Uhr
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...
Bitte warten ..
Mitglied: Mystery-at-min
07.03.2021 um 13:03 Uhr
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.
Bitte warten ..
Mitglied: mtaiit
07.03.2021 um 13:41 Uhr
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
1 - Klicke auf das Bild, um es zu vergrößern2 - Klicke auf das Bild, um es zu vergrößern3 - Klicke auf das Bild, um es zu vergrößern4 - Klicke auf das Bild, um es zu vergrößern5 - Klicke auf das Bild, um es zu vergrößern6 - Klicke auf das Bild, um es zu vergrößern7 - Klicke auf das Bild, um es zu vergrößern8 - Klicke auf das Bild, um es zu vergrößern9 - Klicke auf das Bild, um es zu vergrößern
Bitte warten ..
Mitglied: dernerd123
07.03.2021 um 13:44 Uhr
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:

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
Bitte warten ..
Mitglied: tikayevent
07.03.2021 um 13:58 Uhr
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.
Bitte warten ..
Mitglied: em-pie
07.03.2021 um 15:32 Uhr
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
Bitte warten ..
Mitglied: themuck
07.03.2021 um 17:54 Uhr
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]."
Bitte warten ..
Mitglied: MysticFoxDE
07.03.2021, aktualisiert um 20:01 Uhr
Moin em-pie,

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.

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
Bitte warten ..
Mitglied: themuck
07.03.2021 um 21:10 Uhr
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."
Bitte warten ..
Mitglied: Th0mKa
07.03.2021 um 21:35 Uhr
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
Bitte warten ..
Mitglied: Dani
07.03.2021 um 21:47 Uhr
Moin,
Microsoft stellt ein PowerShell Skript zur Überprüfung bereit: CSS-Exchange


Gruß,
Dani
Bitte warten ..
Mitglied: EDVMan27
07.03.2021 um 23:01 Uhr
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.
Bitte warten ..
Mitglied: StefanKittel
07.03.2021, aktualisiert um 23:26 Uhr
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
Bitte warten ..
Mitglied: B4dmin
07.03.2021, aktualisiert um 23:48 Uhr
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



Was denkt ihr? Abschalten und neu aufsetzen?
Bitte warten ..
Mitglied: StefanKittel
07.03.2021 um 23:40 Uhr
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.
Bitte warten ..
Mitglied: B4dmin
07.03.2021 um 23:46 Uhr
Was meinst du mit Zahl am Ende?



anbei mal die komplette Zeile:


Bitte warten ..
Mitglied: StefanKittel
07.03.2021 um 23:56 Uhr
500 = Serverfehler
200 = Zugriff erfolgreich, Die Datei wurde aufgerufen
Aber Javascript läuft im Browser und nicht auf dem Server

Strange
Bitte warten ..
Mitglied: Dani
08.03.2021 um 00:09 Uhr
Moin,
was ist das Ergebnis des Nmap Skripts von Microsoft?


Gruß,
Dani
Bitte warten ..
Mitglied: MysticFoxDE
08.03.2021 um 01:22 Uhr
Moin Dani,

bei mir sagt Nmap.
nmap - Klicke auf das Bild, um es zu vergrößern

😀

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

Grüsse aus BaWü

Alex
Bitte warten ..
Mitglied: MysticFoxDE
08.03.2021 um 01:31 Uhr
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
Bitte warten ..
Mitglied: Lochkartenstanzer
08.03.2021 um 06:45 Uhr
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
Bitte warten ..
Mitglied: B4dmin
08.03.2021, aktualisiert um 07:14 Uhr
Hattest du also gar nichts auf dem System gefunden @alex
Bitte warten ..
Mitglied: MysticFoxDE
08.03.2021, aktualisiert um 08:36 Uhr
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
Bitte warten ..
Mitglied: MysticFoxDE
08.03.2021, aktualisiert um 08:38 Uhr
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
Bitte warten ..
Mitglied: B4dmin
08.03.2021, aktualisiert um 08:25 Uhr
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.
Bitte warten ..
Mitglied: MysticFoxDE
08.03.2021, aktualisiert um 08:35 Uhr
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
Bitte warten ..
Mitglied: B4dmin
08.03.2021 um 09:10 Uhr
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ß
Bitte warten ..
Mitglied: Lochkartenstanzer
08.03.2021 um 09:21 Uhr
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
Bitte warten ..
Mitglied: LauneBaer
08.03.2021, aktualisiert um 09:38 Uhr
Guten Morgen zusammen,

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


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:
download - Klicke auf das Bild, um es zu vergrößern
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
Bitte warten ..
Mitglied: em-pie
08.03.2021 um 09:27 Uhr
Zitat von @MysticFoxDE:
Moin em-pie,
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.
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. 🤢🤮
Meinen "Glückwunsch" :-( face-sad

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...
Bitte warten ..
Mitglied: MysticFoxDE
08.03.2021 um 09:27 Uhr
Moin B4dmin,

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


Gruss Alex
Bitte warten ..
Mitglied: B4dmin
08.03.2021 um 09:31 Uhr
Ja das ist klar.

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

Was würdet ihr denn machen?
Bitte warten ..
Mitglied: MysticFoxDE
08.03.2021 um 09:33 Uhr
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
Bitte warten ..
Mitglied: Lochkartenstanzer
08.03.2021, aktualisiert um 09:54 Uhr
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
Bitte warten ..
Mitglied: em-pie
08.03.2021 um 09:49 Uhr
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.
Bitte warten ..
Mitglied: MysticFoxDE
08.03.2021 um 09:51 Uhr
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
Bitte warten ..
Mitglied: Vision2015
08.03.2021 um 10:24 Uhr
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
Bitte warten ..
Mitglied: themuck
08.03.2021, aktualisiert um 10:28 Uhr
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...
Bitte warten ..
Mitglied: MysticFoxDE
08.03.2021 um 10:36 Uhr
Moin Frank,

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

warum genau?

Gruss Alex
Bitte warten ..
Mitglied: Lochkartenstanzer
08.03.2021 um 11:21 Uhr
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
Bitte warten ..
Mitglied: Dani
08.03.2021, aktualisiert um 11:28 Uhr
@MysticFoxDE, @B4dmin
nachstehend eine Ausgabe bei einem positven Ergebnis:

Hast du den Screenshot vor oder nach dem Patchen erstellt?


Gruß,
Dani
Bitte warten ..
Mitglied: Vision2015
08.03.2021 um 11:29 Uhr
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
Bitte warten ..
Mitglied: Dani
08.03.2021 um 11:33 Uhr
@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
Bitte warten ..
Mitglied: LauneBaer
08.03.2021 um 12:09 Uhr
Zitat von @Dani:

@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?

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

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?

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
Bitte warten ..
Mitglied: Dani
08.03.2021 um 12:17 Uhr
@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
Bitte warten ..
Mitglied: MysticFoxDE
08.03.2021 um 13:06 Uhr
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
Bitte warten ..
Mitglied: Lochkartenstanzer
08.03.2021 um 13:14 Uhr
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
Bitte warten ..
Mitglied: MysticFoxDE
08.03.2021, aktualisiert um 13:41 Uhr
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
Bitte warten ..
Mitglied: LauneBaer
08.03.2021, aktualisiert um 13:44 Uhr
Zitat von @Dani:

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

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
Bitte warten ..
Mitglied: Dani
08.03.2021, aktualisiert um 13:47 Uhr
@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
Bitte warten ..
Mitglied: Vision2015
08.03.2021 um 13:55 Uhr
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 :-) face-smile


Frank
Bitte warten ..
Mitglied: samrein
08.03.2021 um 15:02 Uhr
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
Bitte warten ..
Mitglied: Dani
08.03.2021 um 15:24 Uhr
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
Bitte warten ..
Mitglied: Vision2015
08.03.2021 um 15:29 Uhr
Moin...

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

Frank
Bitte warten ..
Mitglied: Coreknabe
08.03.2021 um 16:10 Uhr
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:

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

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ß
Bitte warten ..
Mitglied: Dani
08.03.2021 um 16:20 Uhr
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
Bitte warten ..
Mitglied: Coreknabe
08.03.2021 um 16:37 Uhr
Hi Dani,

sorry, vergessen, das ist ein Exchange 2013.

Gruß
Bitte warten ..
Mitglied: LauneBaer
08.03.2021, aktualisiert um 17:05 Uhr
Zitat von @Coreknabe:

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

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:

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

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

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
Bitte warten ..
Mitglied: Vision2015
08.03.2021 um 17:11 Uhr
Zitat von @LauneBaer:

Zitat von @Coreknabe:

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

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:

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

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 ...
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
Bitte warten ..
Mitglied: Dani
08.03.2021, aktualisiert um 17:27 Uhr
@Coreknabe
Was ist mit meiner ersten Frage? :-( face-sad
Bitte warten ..
Mitglied: Vision2015
08.03.2021 um 17:23 Uhr
moin...
Zitat von @Dani:

Was ist mit meiner ersten Frage? :-( face-sad
Sorry, habe ich was übersehen, welche Frage?

Frank
Bitte warten ..
Mitglied: Dani
08.03.2021 um 17:27 Uhr
Sorry Frank! Mein Fehler, Usernamen vergessen.
Bitte warten ..
Mitglied: Coreknabe
08.03.2021 um 17:31 Uhr
@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*
Bitte warten ..
Mitglied: Dani
08.03.2021 um 17:33 Uhr
@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. :-) face-smile
Bitte warten ..
Mitglied: Coreknabe
08.03.2021 um 17:41 Uhr
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:

Bitte warten ..
Mitglied: Dani
08.03.2021 um 17:44 Uhr
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
Bitte warten ..
Mitglied: Coreknabe
08.03.2021, aktualisiert um 18:02 Uhr
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

Bitte warten ..
Mitglied: Dani
08.03.2021 um 18:03 Uhr
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. :-) face-smile
Was geschieht wenn du den Aufruf mit dem Paramter für das URL Rewrite module trotzdem angibst.


Gruß,
Dani
Bitte warten ..
Mitglied: Coreknabe
08.03.2021 um 18:03 Uhr
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...
Bitte warten ..
Mitglied: Drohnald
08.03.2021 um 18:05 Uhr
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
Bitte warten ..
Mitglied: Vision2015
08.03.2021 um 18:23 Uhr
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 :-) face-smile
hast du nach dem Restore mal noch mal
und
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
Bitte warten ..
Mitglied: MysticFoxDE
08.03.2021, aktualisiert um 19:35 Uhr
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
Bitte warten ..
Mitglied: Coreknabe
08.03.2021, aktualisiert um 20:25 Uhr
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 :-) face-smile 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...
Bitte warten ..
Mitglied: MysticFoxDE
08.03.2021, aktualisiert um 20:52 Uhr
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.


backend - Klicke auf das Bild, um es zu vergrößern

(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?
Bitte warten ..
Mitglied: Coreknabe
08.03.2021 um 21:56 Uhr
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


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

Gruß
Bitte warten ..
Mitglied: Mystery-at-min
08.03.2021 um 22:30 Uhr
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.
Bitte warten ..
Mitglied: Coreknabe
09.03.2021, aktualisiert um 07:57 Uhr
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":


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ß
Bitte warten ..
Mitglied: wieoderwas
09.03.2021 um 10:00 Uhr
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...


Ob Daten abgeflossen sind kann ich nun noch nicht bestätigen.
Bitte warten ..
Mitglied: Vision2015
09.03.2021 um 11:38 Uhr
moin
Zitat von @wieoderwas:

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


Ob Daten abgeflossen sind kann ich nun noch nicht bestätigen.
ich denke, das wird auch kaum möglich sein...

Frank
Bitte warten ..
Mitglied: LauneBaer
09.03.2021 um 13:04 Uhr
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
Bitte warten ..
Mitglied: Vision2015
09.03.2021 um 16:54 Uhr
Zitat von @LauneBaer:
Moin...

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:
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
Bitte warten ..
Mitglied: Lochkartenstanzer
09.03.2021 um 17:16 Uhr
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
Bitte warten ..
Mitglied: StefanKittel
09.03.2021, aktualisiert um 17:33 Uhr
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.
Bitte warten ..
Mitglied: Vision2015
09.03.2021 um 18:44 Uhr
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.
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.

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 :-) face-smile

Frank
Bitte warten ..
Mitglied: MysticFoxDE
09.03.2021, aktualisiert um 20:07 Uhr
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
Bitte warten ..
Mitglied: Lochkartenstanzer
09.03.2021 um 20:12 Uhr
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
Bitte warten ..
Mitglied: Coreknabe
09.03.2021 um 21:33 Uhr
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!
Bitte warten ..
Mitglied: MysticFoxDE
10.03.2021, aktualisiert um 08:10 Uhr
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"
Bitte warten ..
Mitglied: Lochkartenstanzer
10.03.2021 um 08:34 Uhr
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
Bitte warten ..
Mitglied: MysticFoxDE
10.03.2021 um 09:47 Uhr
Moin Zusammen,

es gibt mittlerweile von Microsoft ein erweitertes Prüfskript.

https://github.com/dpaulson45/HealthChecker

Grüsse aus BaWü
Alex
Bitte warten ..
Mitglied: LauneBaer
10.03.2021 um 10:42 Uhr
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
Bitte warten ..
Mitglied: em-pie
10.03.2021 um 13:15 Uhr
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
Bitte warten ..
Mitglied: Dani
10.03.2021, aktualisiert um 18:29 Uhr
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. ;-) face-wink 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
Bitte warten ..
Mitglied: em-pie
13.03.2021, aktualisiert um 10:12 Uhr
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.
Bitte warten ..
Mitglied: Mystery-at-min
13.03.2021 um 10:15 Uhr
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?
Bitte warten ..
Mitglied: Vision2015
13.03.2021 um 11:31 Uhr
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
Bitte warten ..
Mitglied: Mystery-at-min
13.03.2021 um 11:34 Uhr
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.
Bitte warten ..
Mitglied: Lochkartenstanzer
13.03.2021 um 11:38 Uhr
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. :-) face-smile

duck und wech

lks
Bitte warten ..
Mitglied: Mystery-at-min
13.03.2021 um 11:41 Uhr
Kommst du gerade aus dem Forum der Grünen? :-) face-smile

Wenn wir von PoC sprachen ist das auch kein people of colo(u)r, sondern ein Meilenstein im Projekt...(Hautfarbenunabhängig)
Bitte warten ..
Mitglied: Dani
13.03.2021 um 11:45 Uhr
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. :-) face-smile


Gruß,
Dani
Bitte warten ..
Mitglied: heilgecht
17.03.2021, aktualisiert um 10:43 Uhr
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
Bitte warten ..
Mitglied: Dani
17.03.2021 um 20:38 Uhr
@heilgecht
autodiscover läuft aber nur ohne Authentifizierung.
Ne, wir haben auch dafür Pre-Authentifizierung im Einsatz.


Gruß,
Dani
Bitte warten ..
Heiß diskutierte Inhalte
Festplatten, SSD, Raid
Festplatte aus defekten Notebook ausgebaut - wird nicht erkannt - Wie gelange ich an meine Daten?
gelöst 1nCoreVor 1 TagFrageFestplatten, SSD, Raid15 Kommentare

Hallo liebe Community, nach 7 Jahren hat mein XMG Notebook seinen Geist aufgegeben In dem Notebook waren zwei Festplatten verbaut (eine für System und ...

Erkennung und -Abwehr
Wie geschickt sich Malware verstecken kann - Ein Beispiel aus der Praxis eines Security Experts
colinardoVor 20 StundenTippErkennung und -Abwehr4 Kommentare

Servus Kollegen und Mitstreiter, da ja in letzter Zeit die Exchange-Lücken die Admin-Landschaft ziemlich aufgewirbelt haben und dabei auch immer mal wieder "sogenannte" Admins ...

Internet
Woher holt sich Android die Kontaktdaten von unbekannten Rufnummern?
gelöst anteNopeVor 1 TagFrageInternet8 Kommentare

Hallo zusammen, seit einiger Zeit merke ich, dass mir mein Android Gerät Namen und Informationen zu mir unbekannten Teilnehmern präsentiert. Soll heißen eine nicht ...

Windows Netzwerk
MS Lizenzierung - externe Scandienstleistung
monstermaniaVor 1 TagFrageWindows Netzwerk9 Kommentare

Hallo Allerseits, ich habe da mal eine Frage an die MS Lizenzspeziallisten. Eine externe Firma soll Scandienstleistungen für uns erledigen. Dazu ist angedacht, dass ...

Exchange Server
Exchange Update CU19 auf CU20 Fehler - Eine weitere Version dieses Produkts ist bereits installiert
gelöst StefanKittelVor 1 TagFrageExchange Server6 Kommentare

Hallo, ich habe hier einen Exchange 2016 mit CU19 (15.1.2176.2). Darauf wollte ich nun CU20 installiert. Download Es erscheint Eine weitere Version dieses Produkts ...

Windows Server
Hat Microsoft die WindowsServerSicherung oder diskpart zerpatcht?
anteNopeVor 15 StundenFrageWindows Server3 Kommentare

Hallo, kann es eventuell sein, dass Microsoft mit seinen letzten Updates die WindowsServerSicherung bzw. diskpart zerschossen hat? Es häufen sich bei mir seit gestern ...

Drucker und Scanner
Epson WF-6590 druckt nur cyan und gelb
gelöst ITCrowdSupporterVor 1 TagFrageDrucker und Scanner15 Kommentare

Guten Tag :-) Es geht um einen Epson Workforce Pro WF-6590. Er druckt nur cyan und gelb obwohl neue Originalpatronen für schwarz und magenta ...

Windows 10
Windows 10 Updates im Abgesicherten Modus nicht möglich!
gelöst Yuuto.LucasVor 1 TagFrageWindows 1016 Kommentare

Hallo, ich habe aktuell ein Problem bei einem Kunden Rechner. Bei diesem gibt es Probleme mit dem Soundkarten Treiber hdaudio.inf wegen dem der PC ...