[English]Die seit Ende Mai 2022 bekannt gewordene Schwachstelle CVE-2022-30190 (Follina) in Windows entwickelt sich langsam zum Problembär. Die von Microsoft und hier im Blog beschriebenen Gegenmaßnahmen erscheinen nicht ausreichend. Ergänzung: Ich habe den aktuellen Diskussionsstand nachgetragen. Die Schwachstelle wird inzwischen zudem von der QakBot-Malware bei Phishing-Angriffen ausgenutzt. Weiterhin sind mir noch Informationen von Cato zur Schwachstelle zugegangen. Hier ein aktualisierter Überblick zum Sachstand.
Anzeige
Rückblick auf CVE-2022-30190
Bei der seit Ende Mai 2022 öffentlich gewordenen Schwachstelle CVE-2022-30190 (aka Follina) kann das Microsoft Support Diagnostics Utility (msdt.exe)über das ms-msdt:-Protokoll missbraucht werden, um bösartige Word-Dokumente (oder Excel-Arbeitsblätter) aus dem Web herunterzuladen. Der Angreifer kann die Sicherheitslücke ausnutzen, um Remote-Code mit den Rechten der aufrufenden Anwendung ausführen.
Ich hatte diesen Sachverhalt im Blog in den Beiträgen Follina: Angriff über Word-Dokumente und ms-msdt-Protokoll (CVE-2022-30190) und Follina-Schwachstelle (CVE-2022-30190): Status, Erkenntnisse, Warnungen & Angriffe aufgegriffen.
Welche Versionen sind betroffen
Betroffen sind laut Microsoft Windows Server 2019 sowie Windows 10 Version 1809 und später, wobei alle Office-Versionen für solche Angriffe missbraucht werden können. Und es hilft auch nicht, wenn die Makroausführung deaktiviert ist. Es gibt sogar die Möglichkeit, über den PowerShell wget-Befehl den Angriff auszulösen, so dass man nicht auf Office angewiesen ist.
Diverse Angriffsmöglichkeiten
Inzwischen sind Angriffe über diese Schwachstelle bekannt, die bereits bis zu sechs Wochen lang stattfinden (siehe Follina-Schwachstelle (CVE-2022-30190): Status, Erkenntnisse, Warnungen & Angriffe). Cato Networks hat mich auf deren Blog-Beitrag Cato Protects Against Microsoft Office Follina Exploits hingewiesen. Dort werden die folgenden drei Angriffsmöglichkeiten erwähnt:
Anzeige
- Benutzer können eine Datei oder Anwendung herunterladen, die die Nutzlast enthält und das Microsoft Support Diagnostics Utility (msdt.exe) lokal aufruft.
- Benutzer können eine Datei oder Anwendung herunterladen, die die Nutzlast enthält und den MSDT-Aufruf aus dem Internet (von den Websites des Angreifers) erhält.
- Der Browser des Benutzers empfängt die Nutzlast in der Antwort auf eine Anweisung von einer bösartigen Website und führt den MSDT aus.
Von Microsoft gibt es bis zum Stand heute keinen Patch zum Schließen dieser Schwachstelle.
Micro-Patch von ACROS Security
Lediglich die Entwickler von ACROS Security haben einen Micro-Patch zum Schließen dieser Schwachstelle in allen von Microsoft noch unterstützten Windows-Systemen veröffentlicht. Der Micro-Patch steht bis zum Zeitpunkt, an dem Microsoft Sicherheitsupdates veröffentlicht, für alle Benutzer kostenlos bereit. Ich habe die Details im Blog-Beitrag 0Patch Micro-Patch gegen Follina-Schwachstelle (CVE-2022-30190) in Windows beschrieben.
Was schützt gegen Follina?
An dieser Stelle stellt sich die brennende Frage, wie man sich vor Angriffen über die Schwachstelle schützen kann.
Virenscanner erkennen das
Der Microsoft Defender besitzt inzwischen eine Signatur, um solche Angriffe über die MSDT-Schwachstelle zu finden und zu eliminieren (siehe auch den Blog-Beitrag Follina: Angriff über Word-Dokumente und ms-msdt-Protokoll (CVE-2022-30190)). Zudem werden Angriffe über diese Schwachstelle inzwischen von weiteren Virenscannern sowie SIEMS-Lösungen erkannt und geblockt.
Cato IPS wehrt Follina ab
Cato Networks hat binnen Stunden Lösungen zur Erkennung (Tactics, Techniques, and Procedures, TTP) und Abwehr entwickelt. Alle drei oben genannten Ansätze werden bereits durch die ATP-Funktionen (Advanced Threat Prevention) von Cato blockiert. Catos Anti-Malware prüft und blockiert das Herunterladen von Dateien oder Anwendungen mit der erforderlichen Nutzlast zur Ausführung von Follina. Cato IPS (Intrusion Prevention System) erkennt und verhindert jeden Aufruf über das Netzwerk oder das Internet.
(Quelle: YouTube)
In obigem Video demonstrieren Sicherheitsexperten von Cato-Network den Angriff über das Internet und zeigen auch, wie dieser Angriff durch die eigenen IPS-Lösungen blockiert werden.
Microsofts Lösungen und GPOs reichen nicht
An dieser Stelle wird es leider (mit dem Diskussionsstand 9. Juni 2022) unschön. Microsoft hat Ende Mai 2022 ein Support-Dokument Guidance for CVE-2022-30190 Microsoft Support Diagnostic Tool Vulnerability veröffentlicht, in dem auch Hinweise zum Abmildern der Schwachstelle gegeben werden. Das Dokument wurde zum 6. und 7. Juni im FAQ-Teil aktualisiert und schließt bestimmte GPOs als Abhilfe aus.
Protokoll-Handler löschen
Im Support-Dokument wird zwar empfohlen, den ms-msdt-Protokoll-Handler durch löschen des Registrierungseintrags
HKEY_CLASSES_ROOT\ms-msdt
zu entfernen. Das soll die Schwachstelle entschärfen. Allerdings ist nicht sichergestellt, dass der ms-msdt-Protokoll-Handler ggf. nicht an anderen Stellen in der Registrierung noch vorhanden ist. Ich weise an dieser Stelle nochmals auf die beiden Kommentare hier und hier in meinem Blog-Beitrag hin, die diesen Sachverhalt aufgreifen.
Microsoft verwirft GPOs
In den Kommentaren (z.B. hier) wird dann empfohlen, doch Gruppenrichtlinien (GPOs) zum Deaktivieren des Microsoft Support Diagnostics Utility (msdt.exe) zu verwenden. Leider ist das ein Placebo, wie Microsoft im Support-Dokument Guidance for CVE-2022-30190 Microsoft Support Diagnostic Tool Vulnerability inzwischen explizit in seiner FAQ als Ergänzung ausführt.
Q: Is configuring the GPO setting Computer Configuration\Administrative Templates\System\Troubleshooting and Diagnostics\Microsoft Support Diagnostic Tool\"Microsoft Support Diagnostic Tool: Turn on MSDT interactive communication with support provider" to "Disabled" another workaround?
A: No, this GPO does not provide protection against this vulnerability. "Interactive communication with support provider" is a special mode MSDT runs in when launched with no parameters which has no impact on MSDT support for URL protocol.
Q: Is configuring the GPO setting Computer Configuration – Administrative Templates – System – Troubleshooting and Diagnostics – Microsoft Support Diagnostic Tool\"Troubleshooting: Allow users to access recommended troubleshooting for known problems" to "Disabled" another workaround?
A: No, enabling or disabling this group policy has no effect on the vulnerable part of Troubleshooter functionality, so it is not a viable workaround.
Wo Microsoft nicht drauf eingeht, ist die von Benjamin Delphy empfohlene Methode, die Richtlinie Problembehandlung: Zugriff und Ausführung von Problembehandlungs-Assistenten durch Benutzer zulassen unter:
Computerkonfiguration\Richtlinien\Administrative Vorlagen\System\Problembehandlung und Diagnose\Skriptdiagnose
auf deaktiviert zu stellen. Das sollte den Aufruf des MSDT unterbinden. Die Richtlinie wirkt sich auf HKLM im Zweig:
SOFTWARE\Policies\Microsoft\Windows\ScriptedDiagnostics
aus und setzt den DWORD-Wert EnableDiagnostics auf Disabled (0). Ob das ausreicht, kann ich nicht final beurteilen – beachtet die nachfolgenden Diskussionen.
Was MSDT blockiert
Microsoft schreibt aber, dass das Blockieren des MSDT über Funktionen wie Windows Defender Application Control (WDAC) die Ausnutzung der Schwachstelle verhindert. Diese Funktion steht aber nur unter Windows 10 Enterprise zur Verfügung. Auch ein Blockieren per Software-Restriction-Policy ist laut diesem Kommentar möglich.
Noch ein Vorschlag
Stefan Kanthak hat mir noch folgenden Hinweis geschickt, den ich hier mal für Administratoren einstelle.
nachdem ja einige Deiner Leser gemerkt haben, dass das MSRC wieder einmal boese geschlampt hat, und Andere (mitdenkend) vorschlagen, den Protokoll-Handler nicht zu Loeschen, sondern dessen Kommandozeile zum Aufruf von MSDT.exe zu ändern und stattdessen ein Programm aufzurufen, dass
1) den Benutzer informiert und
2) in's Ereignisprotokoll schreibt[hier meine Ergänzung]: Genau das macht SENTINEL.EXE (Download hier), den ich nicht umsonst "Vulnerability & Exploit Detector" nenne.
Kopiere die 32-bittige Version in's Windows-Verzeichnis und passe die Kommandozeile an. Danach öffnest Du
<https://skanthak.homepage.t-online.de/follina.html> und befolgst die Hinweise …
Vielleicht hilft es weiter.
Qakbot-Malware-Familie nutzt Follina
Vor Tagen hatte ich im Blog-Beitrag Follina (CVE-2022-30190): Angriffswelle ausgeblieben, aber Kampagnen auf EU/US und andere Ziele noch als Status-Abgleich die Erkenntnis festgehalten, dass bisher die große Angriffswelle ausgeblieben sei. Nur staatliche Akteure scheinen die Schwachstelle gezielt für Angriffe auf ausgesuchte Opfer einzusetzen.
Das ändert sich aber gerade, wie obiger Tweet nahelegt. Ein Sicherheitsforscher ist auf ein Malware-Sample gestoßen, welches den Angriffsvektor verwendet. Das Sample stammt aus der Qakbot-Malware-Familie, deren Entwickler haben also die Schwachstelle inzwischen adaptiert. Auch dieser Tweet von Proofpoint weist in diese Richtung. Die Kollegen von Bleeping Computer haben einige Hinweise dazu in diesem Blog-Beitrag zusammen getragen.
Wurde auf die URL zugegriffen?
Und zum Abschluss noch ein Fundsplitter, der mir unter die Augen gekommen ist. Der nachfolgende Tweet löst die Frage, wie man ggf. feststellen kann, ob jemand unter Word ggf. auf eine URL zugegriffen hat.
Ähnliche Artikel:
Follina: Angriff über Word-Dokumente und ms-msdt-Protokoll (CVE-2022-30190)
Follina-Schwachstelle (CVE-2022-30190): Status, Erkenntnisse, Warnungen & Angriffe
0Patch Micro-Patch gegen Follina-Schwachstelle (CVE-2022-30190) in Windows
Follina (CVE-2022-30190): Angriffswelle ausgeblieben, aber Kampagnen auf EU/US und andere Ziele
Anzeige
Sehr verwirrende GPO Hinweise von Microsoft. Der quick and dirty fix von Benjamin Delpy funktioniert in meinem Test (POC).
Twitter Diskussion hierzu: https://twitter.com/0x446172696F/status/1534136757796610053?s=20&t=UoSE-HjP0O2-QDrPiKukCg
https://twitter.com/GossiTheDog/status/1534134972617048064?s=20&t=UoSE-HjP0O2-QDrPiKukCg
Ist natürlich die Frage, ob Microsoft vielleicht mehr Erkenntnisse hat. Die werden den Code ihres Troubleshooters ja sicherlich unter die Lupe genommen haben oder wissen von Implementationen, die sonst niemand auf dem Schirm hat.
Verstehe ich es richtig, dass der einzige Microsoft-Weg zur Korrektur das Löschen des msdt-Protokolls ist – bei dem wir nicht mal wissen, ob das wirklich hilft?
Na super.
Das ist der Stand der Diskussion.
oder mit Application Controll die Ausführung von "C:\Windows\System32\msdt.exe" verhindern.
Prognose zum Fixverlauf: "Protocol Nightmare" aka "Backdoor schliessen ohne Backdoor zu schliessen"
Printnightmare ging mir durch den Kopf – aber ich kann das Ganze – speziell die GPO-Thematik – nicht abschließend würdigen. Noch gibt es ja keinen Fix, sondern nur "Abschwächungsempfehlungen" – wobei mir die 0patch-Lösung am besten gefällt (die ACROS Security-Leute sind schon gut), nur ist es für Administratoren in Firmenumgebungen schwierig, eine Drittanbieterlösung zu verwenden.
Die 0patch-Lösung dürfte auch andere Backdoors über andere Wege zum "Systemeigenen Host für Skriptdiagnose" aushebeln, wird in der Tat spannend wie Microsoft damit umgeht.
Ich kann leider die verlinkte Seite
https://skanthak.homepage.t-online.de/follina.html
nicht aufrufen. Hat noch jemand dieses Problem?
Fehlermeldung im Firefox: SSL_ERROR_RX_RECORD_TOO_LONG
Fehlermeldung im Edge: ERR_SSL_PROTOCOL_ERROR
Vielleicht liegts auch nur an meiner Firewall..
Ich arbeitet hier mit dem Chromium-Clone Ungoogled, keine Probleme. Habe es gerade im Firefox getestet (Win 7) – auch kein Problem. Hier ein Screenshot der Seite mit den Infos – falls Du nicht an die Seite kommst.
Zum Vergrößern anklicken.
Die Seite funktioniert bei mir problemlos.
Win7,
ungoogled Chromium 102.0.5005.63 oder Firefox 101.0,
DNS Server 1.1.1.1 oder 9.9.9.9
Ja, den Fehler bekomme ich auch.
Zusätzlich meldet sich aber auch mein Virenscanner das er die Seite als Hoch Risiko einstuft und blockiert.
Zu deiner Virenscanner-Thematik – hatte ich u.a. im Beitrag AdwCleaner 8.0.6 schließt erneut DLL-Hijacking-Schwachstelle mal erläutert.
Stefan Kanthak macht sich also den Spaß, den Besuchern zu zeigen, wie die Browser-Entwickler und Virenscanner-Anbieter sich da schön ins Gehege kommen. Möglicherweise hat er den Data-String modifiziert – da er hier i.d.R. mitliest, antwortet er ggf.
Könnte auch die Erklärung sein, warum der oben skizzierte Fehler kommt – eine Sicherheitslösung verheddert sich beim SSL-Dekodieren?
Hinweis des Virenscanners:
Location: skanthak.homepage.t-online.de/follina.html
Access has been blocked as the threat Mal/HTMLGen-A has been found on this website.
Sowas ähnliches bekomme ich von unserem Proxy auch. Ich kann also die Follina-Seite nicht aufrufen. Schade.
Aber gut, msdt.exe ist hier per Applocker gesperrt, bis es Patches dafür gibt.
Wenn ich die Seite in OpenSUSE Tumbleweed mit Firefox öffne gibt es keine Probleme, aber wenn ich Chromium versuche, dann erscheint ein Popup, dass die Skanthak-Webseite eine App "XDG-Open" öffnen möchte.
Wenn ich das dann erlaube, dann erscheint folgende Fehlermeldung:
ms-msdt:%2Fid PCWDiagnostic %2Fmoreoptions false %2Fskip true %2Fparam IT_AutoTroubleshoot%3D%22ts_AUTO%22 %2Fparam IT_BrowseForFile%3D%22file%3A%2F%2FC%3A%2FWindows%2FSystem32%2FCmd.exe%22 %2Fparam IT_SelectProgram%3D%22NotListed%22
Ich gehe mal davon aus, dass das ein beabsichtigter Test ist, ob die ms-msdt Sicherheitslücke offen oder zu ist.
Das steht da ja auch so im Klartext auf der Seite:
"Purpose
Demonstrate the remote code execution vulnerability"
Die Virenscanner bei euch erkennen den Test als Angriffsversuch und blocken die Seite.
"In den Kommentaren (z.B. hier) wird dann empfohlen, doch Gruppenrichtlinien (GPOs) zum Deaktivieren des Microsoft Support Diagnostics Utility (msdt.exe) zu verwenden. "
evtl. sollte dsa Tool msdt.exe per Applocker Richtlinie geblockt werden, bis ein Patch da ist…..
Mach das, hier habe ich das schon letzte Woche gemacht.
Registry-Forensic: Der oben genannte Key
$URL_Office = get-itemproperty -Path registry::HKEY_CURRENT_USER\SOFTWARE\Microsoft\Office\16.0\Common\Internet\
$URL_Office.UseRWHlinkNavigation
wurde von einem Klick in Outlook ausgefüllt und enthielt "mailto: "
Aber nicht die letzte verwendete, sondern eine auf die vor langer Zeit einmal geklickt worden sein muss.
Ein interessanter Key, gibt es da noch mehr Informationen?
Anderer Vorschlag, der eventuell etwas leichter zu integrieren ist als SRP/Applocker/Application Allowlisting ist: NTFS Berechtigungen per GPO auf die Datei setzen und die "Benutzer" aus der ACL entfernen.
https://www.gruppenrichtlinien.de/artikel/powershell-fuer-benutzer-verbieten
Andersrum ist's besser: eine DENY-ACL gegen "Ausführen" für die Benutzergruppe JEDER
ICACLS.exe "%SystemRoot%System32msdt.exe" /Deny *S-1-1-0:(X)
Siehe u.a. https://skanthak.homepage.t-online.de/!execute.html
Bei dem iactls Befehl kommt die Fehlermeldung
"Zugriff verweigert", obwohl die Konsole Adminrechte hat.
Auch im Dateimanager kann ich unter Eigenschaften, Sicherheit, keine Benutzer hinzufügen oder editieren, trotz Adminrechten.
Da braucht man also noch höhere Systemrechte des "TrustedInstaller", denn nur dieser hat Vollzugriff, wie aber kann man diese als Admin erlangen?
Bei deinen beiden Links kommt die Fehlermeldung
"The requested file does not exist."
für Win7:
Rechtsklick auf c:\Windows\system32\msdt.exe, Eigenschaften,
Reiter Sicherheit,
"TrustedInstaller" anklicken,
unten rechts auf "Erweitert",
Reiter "Besitzer",
"Bearbeiten" anklicken,
Administrator bzw einen der anderen Admin-Accounts anklicken (1),
OK,
OK (nochmal bestätigen),
Danach ist für Änderungen an der Datei msdt.exe nicht nur der TrustedInstaller berechtigt, sondern auch die Admins und danach funktioniert der iactls Befehl auch.
(1)
oder auf "Weitere Benutzer und Gruppen",
"Erweitert",
"Jetzt suchen",
in der Liste den Benutzer oder die Gruppe, zum Beispiel "Jeder" suchen und anklicken,
OK,
OK,
OK
Ein weiterer Schritt ist notwendig:
Reiter "Berechtigungen",
"Administratoren" anklicken,
Berechtigungen ändern",
"Administratoren" anklicken,
"Bearbeiten",
"Vollzugriff" anhaken,
OK,
OK,
OK
Das Problem:
Wenn man bei Benutzergruppe "Jeder" die Berechtigung für "Ausführen" entfernt, dann bleibt die Berechtigung "Ausführen" bei der Benutzergruppe "Admin" etc trotzdem weiterhin bestehen, obwohl "Admin" eigentlich eine Untergruppe von "Jeder" sein müsste.
Haben Admins jetzt trotzdem Ausführungsberechtigung, obwohl diese Berechtigung von "Jeder" ausdrücklich entzogen wurde und muss man deswegen diese Ausführungsberechtigung nochmal ausdrücklich auch für alle anderen Gruppen wie "Admins" eintragen?
Deswegen per GPO. Die Security CSE läuft als .\SYSTEM. Zudem möchte man nicht an x-Rechner gehen, um dort den icacls Befehle abzusetzen oder ihn per Script anzustossen (egal ob GPO oder Deployment Tool), wenn es das als native CSE gibt.
Schau mal nach ExecTI von WinAero. Alternativ mit PSExec Systemrechte holen.
AUTSCH: Finger weg von solchem ÜBERFLÜSSIGEN, von AHNUNGSLOSEN verbrochenen SCHROTT!
JFTR: der Missbrauch von TAKEOWN.exe alias "Besitzübernahme" zeugt ebenso von AHNUNGSLOSIGKEIT!
Unter SYSTEM-Konto laufende Prozesse (beispielsweise Startup/Shutdown-"Skripts"; siehe https://skanthak.homepage.t-online.de/tidbits.html#scripts) haben die Privilegien "Backup" und "Restore", dank derer ACLs ignoriert werden.
Mitglieder der Gruppe Administratoren haben diese Privilegien ebenfalls, aber INAKTIV; sie können beispielsweise per https://skanthak.homepage.t-online.de/tidbits.html#twiddler oder einem simplem VB-Skript aktiviert werden.
Soll ich mit *.INF weitermachen?
Stimmt in dem Fall der msdt.exe, Danke! Ich war im Kopf bei der PoSH, die man als Administrator doch verwenden möchte.
"Bei der seit Ende Mai 2022 öffentlich gewordenen Schwachstelle CVE-2022-30190 (aka Follina) kann das Microsoft Support Diagnostics Utility (msdt.exe)über das ms-msdt:-Protokoll missbraucht werden, um bösartige Word-Dokumente (oder Excel-Arbeitsblätter) aus dem Web herunterzuladen."
Umgekehrt ist's richtig: der vor 2 Monaten entdeckten Angriff nutzte eine *.DOCX, um eine *.HTML zu laden, die dann (per JavaScript; geht aber auch ohne) eine "ms-msdt." URL aufruft. Diese dreifache Indirektion unterdrückt u.a. den Prompt (was ich bei meiner "follina"-Seite mit Absicht NICHT mache).
JFTR: follina.html enthält KEINEN EICAR (d.h. Virenscanner erkennen etwas Anderes), sondern ruft mit 3 verschiedenen Methoden eine ms-msdt: URL auf: 1) per LINK REL="preload" HREF=…, 2) per IFRAME SRC=…, 3) per JavaScript beim Klick auf irgendwas in der Seite
Die Unterseite nicht, aber die Hauptseite schon… Leider ist diese Seite daher für mich nicht besuchbar, dabei hat die durchaus wertvolle Tipps.
Unsere Sophos Firewall blockiert bereits den Zugriff auf diesen Artikel, musste ihn auf dem Handy lesen.
Die Verwirrung die hier MS stiftet ist grandios. Weil die berichten über komplett andere Einstellungen.
Wie Günter schon schreibt, ist das EnableDiagnostics das einzig Richtige im Moment, wenn man keine Enterprise Version mit Applocker hat.
Also: einfach MSDT per GPO BLOCKIEREN bis auf weiteres.
Wobei, dies gilt für "Benutzer"-Berechtigungs Umgebungen, nicht für User die ADMIN Rechte haben weil dort lässt sich die Policy ja ansonsten einfach aus der REG entfernen…
Hilft denn diese GPO auch gegen die Methode "WGET und Powershell"?
Laut dem Artikel vom 31.Mai hilft das nicht.
Also doch besser die Ausführungsberechtigung für die Datei msdt.exe für sämtliche Benutzer entziehen.
Habe es über die Software restrictions gelöst und einfach die msdt.exe blockiert. Funktioniert auf hunderten Rechnern problemlos und gab bis jetzt auch noch keine Beschwerden.
Das eigentliche Problem ist wie bei 0patch gut beschrieben in IT_BrowseForFile in TS_ProgramCompatibilityWizard.ps1 wo der darin im Gegensatz zu anderen Stellen nicht "escapte" Parameter von sdiagnhost.exe und dort wiederum über einen DCOM Prozess svchost.exe von msdt.exe ankommt.
Wer sich mit dem Blockieren von msdt.exe oder dem Deaktivieren des ms-msdt Protokolls sicher fühlt, versteht (leider) die grundlegenden Zusammenhänge (noch) nicht und berücksichtigt nicht, dass es weitere zig andere Wege geben könnte, die auch zum o.g. IT_BrowseForFile führen könnten. :-/
Ich denke mal, auf einem ordentlich, automatisch gepatchten System besteht noch nicht mal Handlungsbedarf. In einer leeren Windows 10 Test-VM von mir ohne Zugriffsrechte auf meine Systeme oder Kenntnis jeglicher Kennwörter, zurückgegangen auf einen Snapshot vom 24. Mai (!!!), habe ich https://skanthak.homepage.t-online.de/follina.html im Uralt-Edge 101.0.1210.53 aufgerufen, bevor der sich aktualisieren konnte. Der hat trotzdem schon gefragt, ob ich wirklich den Dateidownload mit Diagnose öffnen möchte, was ich dann mal bejahte habe (aber wer macht sowas?). Und dann hat der Windows Defender sofort zugeschlagen, obwohl der nach dem Starten der VM auch nur wenige Sekunden Zeit hatte, sich ggf. zu aktualisieren, und den Trojan:Win32/Mesdetty.A erkannt und abgewehrt.
Auch ESET soll es laut deren Forum als Win32/Exploit.CVE-2022-30190 erkennen, aber ich habe keine nackte Test-VM mit deren Testversion aktuell konfiguriert, vertraue einfach auf deren Kompetenz, die mich und alle Kunden bislang nie enttäuscht hat dank Nullbefall. Und auf meinem System rufe ich solche Testsites ungeschützt nicht auf. Der 1. Versuch in der Windows 11 Sandbox zeigte überhaupt keine Reaktion außer den Webseiten-Inhalt.
Trotzdem bin ich vor Tagen der Microsoft-Empfehlung gefolgt …2022/05/30/guidance-for-cve-2022-30190-…