Exchange-0-day-Exploit 2022
Ende Sept 2022 gab es erste Berichte über einen Exchange 0-Day Exploit, der im asiatischen Raum auch für Angriffe verwendet werden soll.
Diese Lücke ist die erste, die Microsoft über den EEMS - Ex Emergency Mitigation Service korrigiert.
BSI Warnung: Neuer 0-Day Exploit in
Microsoft Exchange Server
https://bsi.bund.de/dok/1074144 ->
https://www.bsi.bund.de/SharedDocs/Cybersicherheitswarnungen/DE/2022/2022-258168-1032.html
https://www.bsi.bund.de/SharedDocs/Cybersicherheitswarnungen/DE/2022/2022-258168-1032.pdf?__blob=publicationFile&v=2
US CISA: Microsoft Releases Guidance on Zero-Day
Vulnerabilities in Microsoft Exchange Server
https://www.cisa.gov/uscert/ncas/current-activity/2022/09/30/microsoft-releases-guidance-zero-day-vulnerabilities-microsoft
Hinweis:
Der erste RegEx von Microsoft nicht in allen Fällen ausreichend.
Update: Microsoft hat am 5. Okt 2022 seine Anleitung
entsprechend aktualisiert.
- Customer Guidance for Reported Zero-day
Vulnerabilities in Microsoft Exchange Server
https://msrc-blog.microsoft.com/2022/09/29/customer-guidance-for-reported-zero-day-vulnerabilities-in-microsoft-exchange-server/
Verlauf
Achtung: Die Lücken werden nicht durch das Security Update vom 11. Okt 2022 abgesichert.
Datum | Aktion |
---|---|
28. Sep 2022 |
Erste Informationen und Gerüchte zu einer neuen Lücke, über die Exchange Server per HTTPS fremdem Code ausführen. |
29. Sep 2022 |
Microsoft bestätigt die Lücke und entsprechende CVE-Einträge wurde zugewiesen |
30. Sep 2022 |
Erste Hinweise die Lücke "CVE-2022-41040" per URLRewrite zu entschärfen. Condition: {REQUEST_URI}} Pattern .*autodiscover\.json.*\@.*Powershell.* Match: Wildcard Microsoft veröffentlicht ein Skript und ein Update über den EEMS - Exchange Emergency Mitigation Service |
02. Okt 2022 |
Die URLRewrite-Regel wird korrigiert (RegEx statt Wildcard) Alt: Match: Wildcard
Neu: Match: RegEx
|
04. Okt 2022 |
Die URLRewrite-Regel wird erweitert RegEx. Alt: .*autodiscover\.json.*\@.*Powershell.* Neu: .*autodiscover\.json.*Powershell.* |
05. Okt 2022 |
Die URLRewrite-Condition wird erweitert, nachdem gezeigt wurde, dass es noch Lücken gibt. VN Microsoft Exchange mitigations bypass CVE-2022-41040, CVE-2022-41082 Alt: {REQUEST_URI}} Neu: Condition: {UrlDecode:{REQUEST_URI}} |
06. Okt 2022 |
Eine Korrektur am Skript EOMTv2 erfolgt. |
07. Okt 2022 |
Updates für EEMS und EOMTv2 um die neuen Konfigurationen anzuwenden. |
08. Okt 2022 |
Erneute Überarbeitung des RegEx. Alt: .*autodiscover\.json.*Powershell.* Neu: (?=.*autodiscover)(?=.*powershell) |
Wer die Konfiguration über den EEMS - Exchange Emergency Mitigation Service machen lässt, sollte mit maximal einer Stunde Verzögerung die Korrekturen erhalten haben. Alle anderen Administratoren müssen jedes mal nacharbeiten.
Angriffsvektor
Betroffen sind aber wohl alle noch unterstützten Exchange 2013 bis 2019-Server. Vielleicht ist auch Exchange 2010 und früher betroffen aber dafür wird es wohl keine Updates geben.
Microsoft is investigating two reported zero-day vulnerabilities affecting
Microsoft Exchange Server 2013, 2016, and 2019. The first vulnerability,
identified as CVE-2022-41040, is a Server-Side Request Forgery (SSRF)
vulnerability, while the second, identified as CVE-2022-41082, allows remote
code execution (RCE) when PowerShell is accessible to the attacker.
Quelle:
https://msrc-blog.microsoft.com/2022/09/29/customer-guidance-for-reported-zero-day-vulnerabilities-in-microsoft-exchange-server/
Die beiden Bugs haben aber schon einen CVE:
- CVE-2022-41040 Microsoft Exchange Server Elevation of Privilege Vulnerability
- CVE-2022-41082 Microsoft Exchange Server Remote Code Execution Vulnerability
Ein Angreifer kann über die Lücke in Autodiscover "CVE-2022-41040" dann die Lücke in der Remote PowerShell "CVE-2022-41082" ausnutzen. Allerdings ist das Risiko etwas niedriger als bei Hafnium Exploit, denn der erste Exploit erfordert einen "authenticated user", um dann den zweiten Exploit auszunutzen.
In these attacks, CVE-2022-41040 can enable an authenticated attacker to
remotely trigger CVE-2022-41082. It should be noted that authenticated access to
the vulnerable Exchange Server is necessary to successfully exploit either of
the two vulnerabilities.
Quelle:
https://msrc-blog.microsoft.com/2022/09/29/customer-guidance-for-reported-zero-day-vulnerabilities-in-microsoft-exchange-server/
Das ist aber dennoch kein Freibrief, denn "Authenticated User" ist keine große Hürde. Der Angreifer kann ja schon gültige Credentials "auf Vorrat" gesammelt haben oder von intern den Angriff starten.
- Customer Guidance for Reported Zero-day Vulnerabilities in Microsoft
Exchange Server
https://msrc-blog.microsoft.com/2022/09/29/customer-guidance-for-reported-zero-day-vulnerabilities-in-microsoft-exchange-server/ - WARNING: NEW ATTACK CAMPAIGN UTILIZED A NEW 0-DAY RCE VULNERABILITY ON
MICROSOFT EXCHANGE SERVER
https://www.gteltsc.vn/blog/warning-new-attack-campaign-utilized-a-new-0day-rce-vulnerability-on-microsoft-exchange-server-12715.html - Neue Zeroday Lücke in Exchange OnPrem-Servern
https://thehackernews.com/2022/09/warning-new-unpatched-microsoft.html
Risiko ist Real!
Im Internet gibt es viele Diskussionen darüber, wie kritisch die Lücke denn nun tatsächlich ist. Verschiedene Administratoren fühlen sich sicher, wenn ihr Exchange Server nicht aus dem Internet und nur per VPN o.ä. erreichbar ist. Zudem ist die Lücke ja nur mit einer gültigen Authentifizierung ausnutzbar und sei damit deutlich weniger Kritisch als der Hafnium Exploit, bei dem ein anonymer Zugriff reicht.
Ich widerspreche diesen Einschätzungen sehr deutlich und beschreibe, warum jeder die Schutzmaßnamen schnellstens umsetzen sollte.
Diesmal muss der Angreifer sich authentifizieren. Aber dies ist keine reale Hürde. Die Angreifer können damit zwar nicht alle Exchange Server der Welt angreifen aber sie können sicher sein, dass durch Credential Stuffing, Phishing und andere Wege die Angreifer zumindest für einige Firmen schon gültige Zugangsdaten haben und nur auf so eine Schwachstelle gewartet haben. Sie starten nun ihre Motoren und nutzen die Zugangsdaten, um von extern erreichbare Exchange Server zu kapern.
Aber auch Server, die nicht direkt erreichbar sind, können von intern angesprochen werden. Die Angreifer können diese "Kunden" erreichen, indem Sie per VPN oder RDP-Verbindungen mithilfe der bekannten Zugangsdaten letztlich einen Innenangriff starten.
Aber selbst wenn das alles nicht möglich ist, dann kann ich als Angreifer eine bösartige Webseite aufsetzen und ihre arglosen Mitarbeiter auf diese Seite lenken. Das heruntergeladene JavaScript kann natürlich auch HTTP-Zugriffe auf andere Webseiten und damit von intern auch ihren Exchange Server erreichen. Da das Skript sogar vom Anwender unter seinem Zugang ausgeführt wird, ist er auch gegenüber dem Exchange Server "authentifiziert".
Ich habe all diese Wege nicht geprüft aber sie erscheinen mit mehr als möglich und daher sollen alle Exchange Server möglichst schnell geschützt werden.
Schutz aktivieren
Mittlerweile haben sie drei Optionen sich gegen die Lücke zu schützen, die alle auf URLSCAN aufsetzen. Über eine entsprechende Regel werden die gefährlichen Zugriffe abgeblockt.
- EEMS
Wenn Sie seit dem Sep 2021 mit Exchange 2016/2019 auch die Funktion EEMS - Exchange Emergency Mitigation Service installiert und aktiviert haben, dann sollte der Patch seit 1. Okt 2022 schon aktiv sein - Exchange On-Premises Mitigation Tool v2
(EOMTv2)
Microsoft stellt ein PowerShell-Script bereit, welches ihren Exchange Server ebenfalls passend konfiguriert. Bei Bedarf installiert es sogar URLRewrite - Manuell
Microsoft (und die MSXFAQ u.a.) beschreiben auf Blogs die manuellen Schritte zur Konfiguration von URLRewrite, damit die bösartigen URLs geblockt werden.
Alle drei Wege bewirken letztlich das gleiche Ergebnis:
Über URLRewrite wird die schädliche REQUEST-URI abgeblockt.
Wenn Sie einen Reverse Proxy oder eine Web Application Firewall einsetzen, dann können Sie auch dort die URLs filtern. Das schützt aber meist nicht gegen Angriffe von Intern. Gehen Sie immer davon aus, dass ein Angreifer vielleicht einen Zugang per VPN oder RDP in ihre Netzwerk hat und dann nicht von extern kommt.
EEMS in Aktion
Nach dem am 29. Sep. 2022 die ersten Meldungen und ein Microsoft Blogartikel erschienen ist, hat Microsoft am 1. Oktober erstmals die Möglichkeit des EEMS - Exchange Emergency Mitigation Service genutzt, um alle Exchange Server automatisch mit einer Konfigurationsänderung zu versehen. Das funktioniert natürlich nur ,wenn:
- Sie nutzen Exchange 2016CU22 oder
Exchange 2019 CU11 und höher
Erst ab dieser Version vom Sep 2021 oder später ist der EEMS Service voranden - Der Exchange Server die URL
https://officeclient.microsoft.com/getexchangemitigations
erreichen kann
Der EEMS pollt regelmäßig diese URL auf Updates - EEMS muss aktiviert ist
Sie können dies auf Organisationslevel und pro Server deaktivieren.
Ob EEMS bei ihnen die Korrektur schon ausgeführt hat, können Sie zum einen per PowerShell prüfen. In meinen Lab mit zwei Servern hat nur ein Server die Konfiguration schon übernommen.
Der EX02 ist aber "Down" und hat daher noch kein Update umgesetzt. Die Änderungen können Sie auch im IIS Manager sehen
Das ist genau das Ergebnis, welche Sie aus der JSON-Datei auch erwarten durften:
Quelle:
https://officeclient.microsoft.com/getexchangemitigations
Etwas lesbarer formatiert:
<RewriteConfiguration> <type>Web</type> <path>IIS:/sites/Default Web Site</path> <section>system.webServer/rewrite/rules</section> <rules> <rule name="EEMS M1.1 PowerShell - inbound" stopProcessing="true"> <match url=".*" /> <conditions> <add input="{UrlDecode:{REQUEST_URI}}" pattern="(?=.*autodiscover)(?=.*powershell)" /> </conditions> <action type="AbortRequest" /> </rule> </rules> </RewriteConfiguration>
Abweichend von der Beschreibung auf dem Microsoft Blog wurden die Änderungen auf der Root-Seite und nicht nur im virtuellen "Autodiscover"-Verzeichnis angelegt. Die von mir vorab von Hand angelegten Einträge wurden nicht entfernt sondern sind ebenfalls noch vorhanden.
Wer Exchange 2016/2019 mit einem aktuell unterstützten Patchstand hat und EEMS funktioniert, ist nicht mehr über HTTPS angreifbar, weil über eine URLRewrite-Regel der IIS die bösen URLs wegblockt.
Achtung
Wenn Sie ein neues Exchange CU installieren, dann wird auch die IIS-Konfiguration neu gemacht und EEMS muss die Änderungen wieder addieren.
Sie sind dann also bis zu einer Stunde "ungeschützt"
- EEMS - Exchange Emergency Mitigation Service
-
Exchange Emergency Mitigation (EM) service -
List of mitigations released
https://learn.microsoft.com/en-us/exchange/exchange-emergency-mitigation-service?view=exchserver-2016#list-of-mitigations-released - New security feature in September 2021
Cumulative Update for Exchange Server
https://techcommunity.microsoft.com/t5/exchange-team-blog/new-security-feature-in-september-2021-cumulative-update-for/ba-p/2783155 - Released: September 2021 Quarterly
Exchange Updates
https://techcommunity.microsoft.com/t5/exchange-team-blog/released-september-2021-quarterly-exchange-updates/ba-p/2779883 - Exchange Server Zero-Day - Emergency
Mitigation Service applied URL Rewrite
https://blog.icewolf.ch/archive/2022/10/01/exchange-server-zero-day-emergency-mitigation-service-applied-url-rewrite.aspx
Exchange On-Premises Mitigation Tool v2 (EOMTv2)
Wer auf seinem Server die Funktion EEMS - Exchange Emergency Mitigation Service nicht nutzen kann oder möchte aber die später beschriebene manuelle Konfiguration zu umständlich findet, kann von Microsoft ein fertiges PowerShell-Script einsetzen.
Download
https://github.com/microsoft/CSS-Exchange/releases/latest/download/EOMTv2.ps1
Das Skript ist mit ca. 600 Lines of Code deutlich umfangreicher als meine Kurzfassung am Ende. Es prüft aber die eigene Version, lädt bei Bedarf ein Update herunter, installiert das eventuell fehlende URLRewrite und kann damit auch Server absichern, bei denen damals bei der Installation URLRewrite oder EEMS nicht installiert wurde. Eine ausführliche Beschreibung finden Sie bei MIcrosoft
- Exchange On-Premises Mitigation Tool v2 (EOMTv2)
https://microsoft.github.io/CSS-Exchange/Security/EOMTv2/
Manuelle Gegenmaßnahme IIS (Teil1)
Microsoft hat aber erste Gegenmaßnahmen veröffentlicht.
Exchange Online Kunden müssen nicht aktiv werden, da Microsoft hier in der Verantwortung steht und angeblich entsprechende Vorkehrungen bereits getroffen wurden.
Seit EEMS funktioniert, sollten Sie keine manuellen Änderungen machen und ggfls. vorherige manuelle Änderungen entfernen.
Achtung:
In der ersten Veröffentlichung hat Microsoft eine Regel
"RequestBlockingRule1" auf das "Autodiscover"-Verzeichnis
angelegt und später auf die Wurzel geändert. Auch EEMS setzt
den Eintrag in der Wurzel im Default Web aber entfernt nicht
einen manuellen Eintrag darunter. Wenn dann der Name
"RequestBlockingRule1" identisch ist, dann kommt der IISManager durcheinander, da eine vererbte und manuelle
Rewrite-Rule nicht den gleichen Namen haben dürfen:
Gehen Sie dann in die "web.config und entfernen Sie
manuell " den Eintrag. Übrigens: Die "Vererbung" von URLScan
scheint IISAdmin zu machen.
Das Problem dabei ist, dass der IIS dann einen "500
URL_Rewrite"-Fehler generiert und Autodiscover nicht mehr
funktioniert.
Siehe dazu auch
URL_Rewrite.
Der temporäre Fix besteht primäre darin, die URLRewrite-Regeln des "Autodiscover"-Verzeichnisses anzupassen.
- IISAdmin starten
- Default Webseite auswählen
- "Default Web Site" auswählen
In ersten Versionen hat Microsoft die Regel auf das Autodiscover-Verzeichnis anwenden lassen - Feature URL_Rewrite auswählen
- Action: Regel addieren
- Request Blocking auswählen
- Pattern ".*autodiscover\.json.*Powershell.*"
eingeben
Früher war es noch der alte Wert. ".*autodiscover\.json.*\@.*Powershell.*" - Bedingung von "{URL}" auf "{UrlDecode:{REQUEST_URI}} " umstellen
Das Bild ist nicht aktuell Die RegEx-Einstellung ist zu
ändern
Microsoft beschreibt nicht, ob Sie "RegEx" oder "Wildcards" nutzen müssen. Wenn ich mit das Pattern anschaue, dann würde ich das auf "REGEX" umstellen.
Wer sehr viele Server hat, wird sich überlegen, wie er die Einstellungen per Skript oder Powershell durchführen kann.
$site = "iis:\sites\Default Web Site\Autodiscover" $filterRoot = "system.webServer/rewrite/rules/rule[@name='CVE-2022-41040,CVE-2022-41082$_']" Clear-WebConfiguration ` -pspath $site ` -filter $filterRoot Add-WebConfigurationProperty ` -pspath $site ` -filter "system.webServer/rewrite/rules" ` -name "." -value @{name='CVE-2022-41040,CVE-2022-41082' + $_ ;patternSyntax='Regular Expressions';stopProcessing='False'} Set-WebConfigurationProperty ` -pspath $site ` -filter "$filterRoot/match" ` -name "url" -value ".*" $list = @{ pspath = $site filter = "$filterRoot/conditions" Value = @{ input = '{UrlDecode:{REQUEST_URI}} ' matchType ='0' pattern ='.*autodiscover\.json.*Powershell.*' ignoreCase ='True' negate ='False' } } Add-WebConfiguration @list Set-WebConfigurationProperty ` -PSPath $site ` -filter "$filterRoot/action" ` -name '.' ` -value @{type='CustomResponse'; statusCode=404; statusReason='Not found'}
Danke in dem Zuge an meinem Kollegen bei Marc Bogadi von Net at Work für die Bereitstellung des Code.
- URL_Rewrite
- Using rule template to generate a request blocking rule
https://learn.microsoft.com/en-us/iis/extensions/url-rewrite-module/request-blocking-rule-template - IIS – PowerShell script to add IIS URL Rewrite Rule
https://myadventuresincoding.wordpress.com/2015/02/06/iis-powershell-script-to-add-iis-url-rewrite-rule/ - Create a http to https URL redirect in IIS with Powershell
https://dbaland.wordpress.com/2019/02/13/create-a-http-to-https-url-redirect-in-iis-with-powershell/ - Set Up and Use the IIS URL Rewrite Module (Step by Step)
https://adamtheautomator.com/iis-url-rewrite/ - Exchange Server Zero-Day Schwachstelle wird aktiv ausgenutzt
https://www.frankysweb.de/exchange-server-zero-day-schwachstelle-wird-aktiv-ausgenutzt/
Manuelle Gegenmaßnahme PowerShell (Teil2)
Es gibt aber noch einen zweiten Angriffsvektor, der aber wohl nur von intern erreicht werden kann. Dazu müssen Sie den Zugriff auf die beiden folgenden Port blockieren:
- HTTP: 5985
- HTTPS: 5986
Wie werden von der "Remote PowerShell" genutzt und müssen von internen Client schon mal gar nicht erreichbar sein. Das ist wieder eine Steilvorlage zur Einrichtung von Firewalls zwischen den Clients und den Exchange Servern, so dass die Exchange Server nicht mehr ungefiltert erreichbar sind.
- Customer Guidance for Reported Zero-day Vulnerabilities in Microsoft Exchange
Server
https://techcommunity.microsoft.com/t5/exchange-team-blog/customer-guidance-for-reported-zero-day-vulnerabilities-in/ba-p/3641494 - Customer Guidance for Reported Zero-day Vulnerabilities in Microsoft
Exchange Server
https://msrc-blog.microsoft.com/2022/09/29/customer-guidance-for-reported-zero-day-vulnerabilities-in-microsoft-exchange-server/ - Autodiscover V2
-
URL Rewrite Module Configuration Reference
https://learn.microsoft.com/en-us/iis/extensions/url-rewrite-module/url-rewrite-module-configuration-reference -
Exchange Server Zero-Day Schwachstelle wird
aktiv ausgenutzt
https://www.frankysweb.de/exchange-server-zero-day-schwachstelle-wird-aktiv-ausgenutzt/
Schutz über Reverse Proxy/HLB
Wenn sie mehrere Exchange Server betreiben, dann nutzen Sie vermutlich einen Loadbalancer davor. Für die Veröffentlichung in das Internet betreiben viele Firmen auch einen Reverse Proxy in der DMZ, durch den alle HTTP-Requests laufen. Wenn diese Systeme nicht nur auf Layer4 umsetzen, sondern selbst die HTTPS-Verbindung aufbrechen (Layer7), dann können sie auch dort URLs filtern. Entsprechende Hinweise haben die Hersteller ebenfalls veröffentlicht.
- Kemp: CVE-2022-41040 / 41082: Zero Day Microsoft Exchange Vulnerabilities
https://support.kemptechnologies.com/hc/en-us/articles/9558614376717-CVE-2022-41040-41082-Zero-Day-Microsoft-Exchange-Vulnerabilities
https://kemptechnologies.com/blog/microsoft-offers-zero-day-exchange-exploit-workaround-loadmaster-load-balancers-block-and-repair-zero-day-attacks/ - Citrix: Reducing zero-day vulnerability in Microsoft Exchange Server with
Citrix Web App Firewall
https://www.citrix.com/blogs/2022/10/04/zero-day-vulnerability-microsoft-exchange-server-with-citrix-web-app-firewall/
https://docs.citrix.com/de-de/citrix-adc/current-release/application-firewall/signature-alerts/signature-update-version-93.html - FBigIP5 K54470807: Mitigating CVE-2022-41082, CVE-2022-41040 with
BIG-IP ASM / Adv WAF Attack Signatures
https://support.f5.com/csp/article/K54470807 - Akamai’s Response to Zero-Day
Vulnerabilities in Microsoft Exchange Server
(CVE-2022-41040 and CVE-2022-41082)
https://www.akamai.com/blog/security-research/akamais-response-zero-day-vulnerabilities-microsoft-exchange-server
Wer Exchange über Akamai veröffentlicht
Achten sie aber auch hier darauf, dass die Updates am Regex-Ausdruck von Microsoft ggfls. nicht aktualisiert wurden. Zudem darf es speziell von intern natürlich keinen "Bypass" für Angreifer geben, die direkt den Exchange Server ansprechen. Denken Sie hier auch z.B. an die EWS-Erreichbarkeit für Exchange Hybrid-Bereitstellungen oder interne Angreifer über gekaperte Mitarbeiter-Konten
Erkennen und Beseitigen
Angeblich hat dieser Fix keine Auswirkungen auf die Funktion von Exchange. Aber er verrät auch viel über den Angriffsvektor:
- Der externe Angriff erfolgt über "Autodiscover V2"
- Anscheinend akzeptiert Autodiscover hinter dem Dateinamen noch weitere Befehle
- Im IIS-Log sollte man solche Angriffe
mit einer Suche nach dem gleichen RegEx
schnell "finden"
Zumindest wenn der Angreifer nicht die Zeilen in den Logs löscht.
Wenn Sie tatsächlich schon "Opfer" sind, weil Sie entweder sehr früh angegriffen wurden oder einfach lange nicht gepatched haben, dann sollten Sie ihren Server und vielleicht sogar ihr gesamtes Netzwerk als kompromittiert betrachten. Ansonsten erst einmal die Gegenmaßnahmen einleiten und Logs sichern.
Was der Angreifer mit den erlangten Berechtigungen angestellt hat, werden die meisten Opfer schon aufgrund fehlender Erfahrung und Logdateien nicht ermitteln können. Mit etwas Glück wurden sie von genau den gleichen Angreifern kompromittiert, bei deren Angriffen die Lücke erkannt wurde.
Dann können Sie auf ihrem Server prüfen, ob es eine dll.dll-Datei gibt die im IIS als Handler für von extern anonym erreichbar Unterverzeichnisse eingetragen wurden. Laut dem GTSC waren die bei befallenen Kunden die folgenden URLs
Opfer1: https://*:443/ews/web/webconfig/ https://*:443/owa/auth/webcccsd/ https://*:444/ews/auto/ https://*:444/ews/web/api/ Opfer2: http://*:80/owa/auth/Current/script/ https://*:443/owa/auth/Current/script/
Sie sehen aber schon, dass zwischen zwei Angriffen sich schon der Pfad geändert hat und das wird nicht die einzige Änderung bleiben. Die von diesen Angreifern genutzte Malware sollten Virenscanner erkennen und daher den Server schützen. Das funktioniert natürlich nur, wenn:
- Sie einen Virenscanner auf dem Exchange Server haben
- Der Virenscanner auch aktuelle Patternfiles nutzt
- Die Angreifer den Schadcode nicht verändert haben
Für die ersten Stunden nach Veröffentlichung der Lücke können Sie davon ausgehen, dass die Angreifer noch ihre funktionierenden Codes verwenden aber es ist nur eine Frage der Zeit, bis andere Angreifer mit dem Wissen um den Fix auch die Lücke finden und mit anderer Malware unterwegs sind. Insofern ist das Erkennen wichtig aber das Beseitigen ein individueller Prozess.
- WARNING: NEW ATTACK CAMPAIGN UTILIZED A NEW 0-DAY RCE VULNERABILITY ON
MICROSOFT EXCHANGE SERVER
https://gteltsc.vn/blog/warning-new-attack-campaign-utilized-a-new-0day-rce-vulnerability-on-microsoft-exchange-server-12715.html - LogParser
- NCSE0Scanner.exe
<link nicht klickbar>: https://github.com/ncsgroupvn/NCSE0Scanner/releases
Soll eine schnelle Suche in IISLogs nach entsprechenden Patterns erlauben - Ich habe den Code nicht verifiziert und der Autor hat sich erst am 29.9.2022 in Github angemeldet. Vielleicht ist die EXE nicht sauber und wartet nur drauf, von einem Administrator auf dem Exchange Server ausgeführt zu werden. Ich würde eher LogParser nutzen.
Weitere Links
- EEMS - Ex Emergency Mitigation Service
- URL_Rewrite
- WARNING: New attack campaign utilized a
new 0-day RCE vulnerability on Microsoft
Exchange Server
https://www.gteltsc.vn/blog/warning-new-attack-campaign-utilized-a-new-0day-rce-vulnerability-on-microsoft-exchange-server-12715.html - Neue Zeroday Lücke in Exchange OnPrem-Servern
https://thehackernews.com/2022/09/warning-new-unpatched-microsoft.html - Customer Guidance for Reported Zero-day Vulnerabilities in Microsoft Exchange
Server
https://techcommunity.microsoft.com/t5/exchange-team-blog/customer-guidance-for-reported-zero-day-vulnerabilities-in/ba-p/3641494 - Customer Guidance for Reported Zero-day Vulnerabilities in Microsoft
Exchange Server
https://msrc-blog.microsoft.com/2022/09/29/customer-guidance-for-reported-zero-day-vulnerabilities-in-microsoft-exchange-server/ - BSI Warnung: Neuer 0-Day Exploit in Microsoft Exchange Server
https://www.bsi.bund.de/SharedDocs/Cybersicherheitswarnungen/DE/2022/2022-258168-1032.html
https://www.bsi.bund.de/SharedDocs/Cybersicherheitswarnungen/DE/2022/2022-258168-1032.pdf?__blob=publicationFile&v=2 - US CISA: Microsoft Releases Guidance on
Zero-Day Vulnerabilities in Microsoft
Exchange Server
https://www.cisa.gov/uscert/ncas/current-activity/2022/09/30/microsoft-releases-guidance-zero-day-vulnerabilities-microsoft - New 0-day vulnerability found in
Microsoft Exchange
https://www.alitajran.com/0-day-vulnerability-microsoft-exchange/#h-latest-updates - Exchange Server werden über 0-day
Exploit angegriffen (29. Sept. 2022)
https://www.borncity.com/blog/2022/09/30/exchange-server-werden-ber-0-day-exploit-angegriffen-29-sept-2022/ - Twitter Meldung
https://twitter.com/GossiTheDog/status/1575580072961982464