[English]Freitag den 13. Januar 2023 waren weltweit Windows-Nutzer von einem fehlerhaften Defender Signatur-Update betroffen, welches über eine ASR-Regel Desktop-Verknüpfungen und mehr löschte. In einer Nachbereitung werfe ich ein Licht darauf, warum auch private Windows 10/11-Nutzer betroffen sein konnten. Und es gibt noch einen Ansatz, die gelöschten Verknüpfungen aus den Volumenschattenkopien zu restaurieren.
Anzeige
ASRmageddon: Was war los?
Am Freitag Vormittag stellten Nutzer und Administratoren fest, dass weltweit auf Windows-Maschinen plötzlich Verknüpfungen auf dem Desktop, in der Taskleiste und im Startmenü gelöscht wurden. Andere Nutzer stellten fest, dass sich Office-Anwendungen plötzlich nicht mehr starten ließen. Ich hatte das Problem zeitnah im Blog-Beitrag Microsoft ASR/Defender-Update löscht Desktop-Shortcuts, Taskleiste kaputt, Office-Apps starten nicht mehr aufgegriffen und eine Ursache angegeben.
Das Signatur-Update Build 1.381.2140.0 (von Microsoft als Security Intelligence-Update bezeichnet) war fehlerhaft. Auf betroffenen Geräten bewirkte die fehlerhafte Signatur bei aktivierter ASR-Regel "Win32-API-Aufrufe von Office-Makros blockieren" ("Block Win32 API calls from Office macro"), dass Verknüpfungen als schädlich erkannt und gelöscht wurden. Das Kürzel ASR steht für Attack Surface Reduction, eine Funktionalität in Windows, um Geräte vor bestimmten Angriffen zu schützen. Später wurde das Ganze von Microsoft in einer Erklärung bestätigt (siehe Windows löscht Verknüpfungen; Microsoft erklärt Windows Defender ASR-Problem vom 13. Jan. 2023). Betroffen waren die folgenden Windows 10/11 Clients:
- Windows 11 21H2 und 22H2;
- Windows 10 20H2 bis 22H2
- Windows 10 Enterprise LTSC 2019
- Windows 10 Enterprise LTSC 2016
- Windows 10 Enterprise 2015 LTSB
sofern ASR aktiviert war. Microsoft meinte zwar, dass das Ganze erst mit dem Windows Defender for Endpoint (Plan 1 und höher) wirksam wurde. Aber es gab auch Berichte von Nutzern, die nur ein Windows 10/11 im Einsatz hatten.
Defender UI-Nutzer auch betroffen
Mir lagen einzelne Stimmen von Nutzern vor, die davon berichteten, auch auf ihren Privatrechnern von den gelöschten Verknüpfungen betroffen worden zu sein. Ad-hoc schien dies unwahrscheinlich, ist dort doch kein Microsoft Defender for Endpoint (ab Plan 1) im Einsatz. Ich habe es mir so erklärt, dass die Betroffenen auf ihren Einzelplatzsystemen vielleicht ASR unter Windows 10 oder Windows 11 mittels Gruppenrichtlinien oder der Powershell aktiviert hatten.
Anzeige
Nun hat sich Blog-Leser Wolf J in diesem Kommentar gemeldet und bestätigte nicht nur, dass Privatanwender betroffen waren. Zu meiner Vermutung "möglicherweise, sofern ASR unter Windows 10/11 über die PowerShell oder Gruppenrichtlinien aktiviert war" schreibt er auch warum es einige Privatnutzer getroffen hat.
Tatsächlich hat sich bei unseren Untersuchungen herausgestellt, dass Privatanwender betroffen waren, die Defender UI eingesetzt hatten.
Der Fehler wurde recht frühzeitig von einem User im Windows 10 Forum gemeldet.
Defender UI ist ein freies Tool, welches eine bessere Benutzeroberfläche für den Microsoft Defender verspricht (siehe folgenden Screenshot von der Webseite der Entwickler). Und mit diesem Tool haben sich die Leute die "Laus im Schafspelz" mit auf die Systeme geholt.
Wolf J. ist der Frage nämlich nachgegangen, warum es doch Privatanwender mit ASRmageddon getroffen hat. In seinem Kommentar schreibt es dann:
Wir konnten das Problem zuerst auch nicht eingrenzen, bis von weiteren Usern die Aussage kam, dass Defender UI im Einsatz war.
Daraufhin habe ich die Software auf einem Testrechner installiert und gesehen, dass auch ohne eigene Änderungen die ASR Rules aktiviert wurden. Schon die Einstellung "warn" reicht aus, um die inzwischen bekannten Auswirkungen zu beobachten.
Per Powershell mit dem Befehl:
Get-MpPreference | select AttackSurfaceReductionRules_Ids, AttackSurfaceReductionRules_Actionskann man sich das ansehen und mit
Remove-MpPreference -AttackSurfaceReductionRules_Idsgezielt löschen. Auch das Zurücksetzen per Defender UI auf "Werkseinstellung" löschte die gesetzten ASR Rules.
An dieser Stelle mein Dank an den Blog-Leser, dass er uns an seinen Erkenntnissen teilhaben lässt. Die Episode zeigt erneut das Risiko, dem man sich mit der Verwendung solcher Tools aussetzt, wenn man nicht genau nachvollzieht, was da genau gemacht wird.
Verknüpfungen zurückholen
Ich hatte bereits in den Blog-Beiträgen Microsoft ASR/Defender-Update löscht Desktop-Shortcuts, Taskleiste kaputt, Office-Apps starten nicht mehr und Windows löscht Verknüpfungen; Microsoft erklärt Windows Defender ASR-Problem vom 13. Jan. 2023 auf Scripte hingewiesen, die die gelöschten Verknüpfungen restaurieren können. Phillipp Schweizer merkt in diesem Kommentar aber an, dass die Microsoft Script-Lösung nicht auf einem lokalisierten Windows funktioniere:
Die Lösung von MS ist echt mies – rollt man das SCript via Intune aus läuft es nicht ordentlich (32/64Bit Problematik), dazu sind die Rechte darin Hard Coded und auf einem deutschen Windows nicht zu gebrauchen.
Was ebenfalls fehlt – hatte der Benutzer die Apps aus dem Startmenu an die Taskleiste gepinnt bleibt der ein weißes Kästchen – das konnten wir via Script ebenfalls noch nicht lösen.
Auf Twitter bin ich aber auf zwei Fundstellen gestoßen, die sich mit der Restaurierung der gelöschten .lnk-Dateien befassen, die ich der Leserschaft nicht vorenthalten möchte.
Wenn der Volumenschattenkopien-Dienst läuft, sollten die gelöschten .lnk-Dateien noch in den Volumenschattenkopien finden. Tero Alhonen weist in obigem Tweet auf eine Lösung hin, die Matt Rouse als Kommentar zum Techcommunity-Beitrag eingestellt hat.
I believe I've found a general purpose command line solution that can be deployed to leverage any existing shadow copies and put shortcuts back on the Start Menu. Shadow copies are predictably named which is helpful. I believe they only persist for a couple of weeks so the contents should be recent enough to be useful as well.
Consider the following script which will mount the last five shadow copies, one-by-one, attempt to copy the contents of the Start Menu folder back to the live location, and then dismount the shadow copy. If the shadow copies don't exist, the command will fail but no damage will be done and nothing will be overwritten. Note this script does require admin privileges.
mklink /d c:\shadowrestore \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1\ robocopy /e /r:1 /w:1 "c:\shadowrestore\ProgramData\Microsoft\Windows\Start Menu\Programs" "C:\ProgramData\Microsoft\Windows\Start Menu\Programs" rmdir c:\shadowrestore mklink /d c:\shadowrestore \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy2\ robocopy /e /r:1 /w:1 "c:\shadowrestore\ProgramData\Microsoft\Windows\Start Menu\Programs" "C:\ProgramData\Microsoft\Windows\Start Menu\Programs" rmdir c:\shadowrestore mklink /d c:\shadowrestore \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy3\ robocopy /e /r:1 /w:1 "c:\shadowrestore\ProgramData\Microsoft\Windows\Start Menu\Programs" "C:\ProgramData\Microsoft\Windows\Start Menu\Programs" rmdir c:\shadowrestore mklink /d c:\shadowrestore \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy4\ robocopy /e /r:1 /w:1 "c:\shadowrestore\ProgramData\Microsoft\Windows\Start Menu\Programs" "C:\ProgramData\Microsoft\Windows\Start Menu\Programs" rmdir c:\shadowrestore mklink /d c:\shadowrestore \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy5\ robocopy /e /r:1 /w:1 "c:\shadowrestore\ProgramData\Microsoft\Windows\Start Menu\Programs" "C:\ProgramData\Microsoft\Windows\Start Menu\Programs" rmdir c:\shadowrestoreThoughts or comments? This seems to work well in my test environment. Note that you can list shadow copies for a volume with the following command:
vssadmin list shadows /for=c:
Hope this helps someone.
Zudem hat Microsoft MVP Nicklas Ahlberg ein Script zum Restaurieren der gelöschten Verknüpfungsdateien veröffentlicht, auf das er in nachfolgendem Tweet hinweist.
Vielleicht hilft eine der obigen Lösungen den Betroffenen weiter.
Ähnliche Artikel:
Microsoft ASR/Defender-Update löscht Desktop-Shortcuts, Taskleiste kaputt, Office-Apps starten nicht mehr
Windows löscht Verknüpfungen; Microsoft erklärt Windows Defender ASR-Problem vom 13. Jan. 2023
Anzeige
Auch mit dem Tool ConfigureDefender trat das Problem auf, wie in einem Blog erwähnt. (https://github.com/AndyFul/ConfigureDefender)
Für "normale" User sind solche Tools sowieso mit Vorsicht zu gebrauchen!
ConfigureDefender (https://github.com/AndyFul/ConfigureDefender) aktiviert ebenfalls bei Prof und Home Versionen ASR.
Mit ShadowExplorer lässt sich bei Home Versionen (dort fehlt der Vorgänger-Tab) die Verknüpfungen aus den Schattenkopien zurückholen, vorausgesetzt Computerschutz war für Laufwerk C: aktiviert.
interessante Ordner für Wiederherstellung:
für StartMenü:
"C:\ProgramData\Microsoft\Windows\Start Menu"
"C:\Users\\AppData\Roaming\Microsoft\Windows\Start Menu"
für Taskleiste:
"C:\Users\\AppData\Roaming\Microsoft\Internet Explorer\Quick Launch"
für Desktop:
"C:\Users\Public\Desktop"
"C:\Users\\Desktop"
Der Windows Defender ist wohl die übleste Datenschleuder aller Zeiten.
Den tot zu machen ist Pflicht.
Jedesmal wenn man eine Datei aufruft, eine .exe startet oder was auch immer sendet dieses Ding eine Anfrage an MS mit den jeweiligen Informationen. Dadurch ensteht ein sagenhafter Marketing Datenschatz für MS. Im Namen der Sicherheit natürlich.
"Den tot zu machen ist Pflicht."
Blödsinn! Entweder kein Antivirenschutz oder Defender! Es gibt keine Alternative, die so sauber im System integriert ist, wie der Defender. (Natürlich kann man ohne Gurt Auto fahren.) Denke nicht, dass andere AV-Lösungen besser sind. Deren Code-Basis gilt als grottig.
Afaik kann man das nachhause schicken der Prüfsummen abstellen.
Irgendwo was mit "smart" oder "share"…
Um niemanden auf falsche Gedanken zu bringen :
Im Deutschland wäre es verboten solche Daten ans Marketing weiterzugeben /dafür auszuwerten.
"Zweckbindung".
Das ist bei anderen Scannern nicht anders.
Es werden jedoch nur Prüfungsummen übermittelt.
Man kann das aber dem Defender untersagen.
Für das Marketing dürfen diese Daten natürlich nicht verwendet werden, aber die NSA(und andere) ird darauf Zugriff haben, wenn sie wollen.
Ich aktiviere bei Neuinstallationen von Windows schon seit 5 Jahren immer eine Auswahl der "ASR"-Regeln per PowerShell. Diese hatten bis zum Freitag noch nie Probleme gemacht, nein, sie haben sogar nachweislich schon mehrere Windows-Nutzer vor infizierten Mail-Anhängen oder Office-Dokumenten geschützt. (Ja, es soll doch tatsächlich immer noch unbedarfte Nutzer geben, die einfach alles, ohne Nachdenken, öffnen.)
Deswegen finde ich es schade, dass hier ASR nun eher negativ angesehen wird und vor den Tools zum Aktivieren gewarnt wird, nur weil Microsoft mal wieder nicht ausreichend getestet hat. ASR sind sinnvoll, insbesondere bei Verwendung von Microsoft Office, und eigentlich sollten dieses am besten auch im GUI des Standard-Defender aktivierbar sein. (Aber Microsoft braucht wohl Verkaufsargumente für die Bezahlversion.)
Der Fehler hätte genau so auch ohne aktivierte ASR passieren können, dies haben Microsoft und andere Hersteller ja schon oft genug bewiesen…
Anonymous sagt: "[…] eine Auswahl der "ASR"-Regeln per PowerShell. […] (Ja, es soll doch tatsächlich immer noch unbedarfte Nutzer geben, […])"
Dann, bitte, laß doch die Community nicht in Unwissenheit sterben, sondern teile die hilfreichen Regeln – danke!
Aber gerne doch:
– Block all Office applications from creating child processes:
d4f940ab-401b-4efc-aadc-ad5f3c50688a
– Block executable content from email client and webmail:
be9ba2d9-53ea-4cdc-84e5-9b1eeee46550
– Block Office applications from creating executable content:
3b576869-a4ec-4529-8536-b80a7769e899
– Block Office applications from injecting code into other processes:
75668c1f-73b5-4cf0-bb93-3ecf5cb7cc84
– Block Office communication application from creating child processes:
26190899-1602-49e8-8b27-eb1d0a1ce869
– Block Win32 API calls from Office macros:
92e97fa1-2edf-4476-bdd6-9dd0b4dddc7b
– Block JavaScript or VBScript from launching downloaded executable content:
d3e037e1-3eb8-44c8-a917-57927947596d
– Use advanced protection against Ransomware:
c1db55ab-c21a-4637-bb3f-a12568109d35
– Block untrusted and unsigned processes that run from USB:
b2b3f03d-6a65-4f7b-a9c7-1c7ef74a9ba4
– Block Adobe Reader from creating child processes:
7674ba52-37eb-4a4f-a9a1-f0f9a1619a2c
Alle Regeln und weiterführende Informationen:
https://learn.microsoft.com/en-us/microsoft-365/security/defender-endpoint/attack-surface-reduction-rules-reference?view=o365-worldwide
https://learn.microsoft.com/en-us/microsoft-365/security/defender-endpoint/enable-attack-surface-reduction?view=o365-worldwide
Wenn auch off-topic, zum Thema Wiederherstellung von Shortcuts an dieser Stelle ein Hinweis auf das kleine Tool namens CloneApp von Builtbybel (ehemals Mirinsoft).
Das Programm ist Gold wert und kommt in unserem Unternehmen zum Einsatz, wenn ein PC-Wechsel ansteht und benutzerspezifische Einstellungen wiederhergstellt werden müssen.
Läuft auch automatisiert über die Aufgabenplanung bzw. einer Batch-Datei.
Nähere Infos:
https://github.com/builtbybel/CloneApp
Unterstützte Programme (manuelle Erweiterung möglich):
https://github.com/builtbybel/CloneApp/blob/master/docs/supported-apps.md
Dokumentation:
https://raw.githubusercontent.com/builtbybel/CloneApp/master/docs/manual.pdf
Gibt doch mittlerweile ein Script von Microsoft, welches verschiedene Verknüpfungen wiederherstellt. Das Powershell Skript lässt sich auch sehr leicht für die eigene Umgebung erweitern, falls da nicht alle Verknüpfungen dabei sind.
Wenn Microsoft Defender seine selbst erzeugten Dateien fälschlicherweise als Malware einstuft und diese löscht, dann müsste es doch genügen, diese aus der Quarantäne wieder herzustellen.
Oder sehe ich da etwas nicht richtig?
Im aktuellen Fall hat der Defender alles ohne Rückfrage direkt gelöscht und daher leider auch nicht in eine Quarantäne verschoben. Finde dieses Vorgehen des Defender sehr fragwürdig…
Die MS-Defender-Skeptiker, wie ich einer bin, erhalten jetzt Auftrieb.
Wie kann man dem MS-Defender vertrauen, wenn er Windows-Dateien fälschlicherweise als Malware einstuft und diese löscht ohne in die Quarantäne zu verschieben.
Ich bleibe bei meinem Drittanbieter-Security-System.
Da kommt so was nicht vor.
Auch wenn das Thema fast schon wieder in Vergessenheit geraten ist, hier noch ein Nachtrag:
Bei den Systemen, welche ich die letzten Tage "reparieren" durfte, ist mir aufgefallen, dass nicht nur die Verknüpfungen gelöscht wurden, sondern leider auch alle "desktop.ini" Dateien! Dadurch werden alle Benutzer- und System-Ordner nur noch mit ihrer englischen Bezeichnung angezeigt. (Es war definitiv die fehlerhafte ASR-Regel, da das Änderungsdatum der betreffenden Ordner immer der 13.01. ist.)
Bisher habe ich bei keinem Bericht im Internet einen Hinweis darauf finden können. Auch Microsoft scheint dies nicht bemerkt zu haben. Leider ist mir keine einfache Methode zur Wiederherstellung dieser Dateien bekannt, außer das umständliche Kopieren von einem andren, nicht betroffenen, System…