[English]In Windows 10 gibt es ja ab der Version 1809 eine gravierende Schwachstelle CVE-2021-36934, die das Auslesen der Security Accounts Manager (SAM)-Datenbank über VSS-Schattenkopien ermöglicht. Das eröffnet lokalen Angreifern die Möglichkeit, sich Privilegien von Administratoren zu verschaffen und sich ggf. in Netzwerken zu bewegen. Inzwischen wird das Potential und der Kreis der betroffenen Maschinen klarer, weshalb ich diesen Nachfolgeartikel veröffentliche.
Anzeige
Die HiveNightmare-Schwachstelle CVE-2021-36934
Im gestrigen Beitrag Windows 10: SAM-Zugriffsrechte ab 1809 nach Upgrade kaputt, Benutzerzugriff möglich hatte ich erste Erkenntnisse zur von Sicherheitsforscher Jonas Lyk entdeckten Schwachstelle in Windows im Blog veröffentlicht. Zu dieser Zeit wurde der Sachverhalt mit Kevin Beaumont und Benjamin Delpi erst für kurze Zeit auf Twitter diskutiert. Mir waren beim Schreiben des Artikels weder der Umfang der betroffenen Maschinen noch die Folgen der Schwachstelle klar. Inzwischen gibt es zahlreiche Rückmeldungen aus der Leserschaft, und sowohl Microsoft als auch das US-CERT haben Sicherheitswarnungen veröffentlicht.
Sicherheitsforscher Kevin Beaumont bezeichnet die Schwachstelle als HiveNightmare – eine Anlehnung an die als PrintNightmare bezeichnete Schwachstelle im Windows Print-Spooler-Dienst. Hive ist der englische Name für die Strukturdateien für die Windows-Registry. Insgesamt existieren im Ordner C:\Windows\system32\config fünf Dateien SYSTEM, SECURITY, SAM, DEFAULT und SOFTWARE. Beaumont hatte bereits gestern ein Tool veröffentlicht, mit dem sich die Security Access Management (SAM) Datenbank dumpen lässt.
Zur Schwachstelle gibt es die Erkenntnis, dass ab Windows 10 Version 1809 die Access Control Lists (ACLs) mit den Berechtigungen für die Hive-Dateien:
c:\Windows\System32\config\sam
c:\Windows\System32\config\system
c:\Windows\System32\config\security
in manchen Szenarien fehlerhaft gesetzt werden. Dann werden der Gruppe der Standardbenutzer Leserechte auf diese Dateien gewährt. Liegen Volumen-Schattenkopie (VSS shadow copy) des Systemlaufwerks vor, kann ein nicht privilegierter Nutzer diese Dateien auslesen, was insbesondere für die Security Accounts Manager (SAM)-Datenbank fatal ist.
Anzeige
Sicherheitswarnung des US-CERT und von Microsoft
Seit der Veröffentlichung meines gestrigen Artikels hat Microsoft den Sicherheitshinweis CVE-2021-36934 veröffentlicht. Darin wird eine Windows Elevation of Privilege-Schwachstelle bestätigt, die eine lokale Rechteerweiterung ermöglicht.
* CVE-2021-36934
– CVE-2021-36934 | Windows Elevation of Privilege Vulnerability
– Version: 1.0
– Reason for Revision: Information published.
– Originally posted: July 20, 2021
– Updated: N/A
– Aggregate CVE Severity Rating: N/A
Die Schwachstelle, die diese Erhöhung der Berechtigungen ermöglicht, besteht aufgrund von zu freizügigen Zugriffskontrolllisten (ACLs) in mehreren Systemdateien, einschließlich der Security Accounts Manager (SAM)-Datenbank. Ein Angreifer, der diese Sicherheitslücke erfolgreich ausnutzt, könnte, so Microsoft im Sicherheitshinweis, beliebigen Code mit SYSTEM-Rechten ausführen.
Ein Angreifer könnte dann Programme installieren, Daten anzeigen, ändern oder löschen oder neue Konten mit vollen Benutzerrechten erstellen. Der Angreifer muss die Möglichkeit haben, Code auf einem Opfersystem auszuführen, um diese Sicherheitslücke auszunutzen. Eine Ausnutzung ist Microsoft nicht bekannt, das Unternehmen untersucht aber noch die Angelegenheit.
Die Sicherheitswarnung des US-CERT ist da viel aussagekräftiger. Will Dormann, der als Analyst für das CERT arbeitet, hat sich mit der Schwachstelle befasst und mit den oben erwähnten Sicherheitsforschern ausgetauscht. Das US-CERT schreibt, dass eine Volumen-Schattenkopie (VSS shadow copy) des Systemlaufwerks einem nicht privilegierten Benutzer den Zugriff u.a. auf diese Dateien (wie die SAM) ermöglicht, was unter anderem für folgende Szenarien verwendet werden kann.
- Kontokennwort-Hashes mit Tools wie mimikatz und Pass-the-Hash aus der SAM-Datenbank extrahieren und für eine Rechteerhöhung ausnutzen
- Das ursprüngliche Windows-Installationspasswort herausfinden
- DPAPI-Computerschlüssel herausfinden. Diese werden zur Entschlüsselung aller privaten Computerschlüssel verwendet
Erbeutete Passwort-Hashes eines Computerkonto ließen sich für einen Silver-Ticket-Angriff verwenden, um sich in einem Netzwerk lateral (seitwärts) zu bewegen. Benjamin Deply hat auf Twitter bereits in einem Video demonstriert, was sich alles damit anstellen lässt.
Kevin Beaumont hat auf doublepulsar.com diesen Artikel zum Thema veröffentlicht. Dort schreibt er auch, dass der unten angegebene Workaround nicht funktioniere, weil die VSS-Schnappschüsse schreibgeschützt seien.
Welche Clients sind betroffen?
Betroffen sind alle Windows 10 Versionen ab der 1809, wobei es egal ist, ob eine Neuinstallation oder ein Upgrade vorliegt. Dies geht bis zur aktuellen Version 21H1 und betrifft auch das neue Windows 11. Lediglich bei Windows 10 20H2 zeichnet sich ab, dass Neuinstallationen nicht betroffen sind. Das würde auch erklären, dass viele Kommentatoren zum Artikel Windows 10: SAM-Zugriffsrechte ab 1809 nach Upgrade kaputt, Benutzerzugriff möglich und auf Facebook die Schwachstelle nicht nachvollziehen konnten. Inwieweit Clients als Mitglied einer Domäne betroffen sind, müsste von den Administratoren geklärt werden.
Gibt es Workarounds?
Blog-Leser Bernhard Diener hat gestern im Blog in diesem Kommentar den Vorschlag gemacht, in einem Batch, der als Task mit administrativen Berechtigungen läuft, die VSS-Schattenkopien mit dem Befehl:
vssadmin delete shadows /all /quiet
zu löschen. Hat den Nachteil, dass alle VSS-Schattenkopien weg sind. Zudem kann der Defender Probleme machen, wie Bernhard im Kommentar ausführt. In diesem Tweet gibt es Hinweise auf Kollateralschäden, falls die VSS-Schattenkopien gelöscht werden.
Beim US-CERT schlägt man als Workaround vor, in einer administrativen Eingabeaufforderung, die nachfolgenden Befehle auszuführen:
icacls %windir%\system32\config\sam /remove "Users"
icacls %windir%\system32\config\security /remove "Users"
icacls %windir%\system32\config\system /remove "Users"
Diese entziehen den drei Hive-Dateien die Zugriffsberechtigungen für die Gruppe der Standardbenutzer. Beachtet aber die Hinweise in den nachfolgenden Kommentaren, das "Users" sich auf ein englischsprachiges Windows bezieht. Im Nachgang sind alle VSS-Schattenkopien des Systemlaufwerks zu löschen – um den Zugriff auf die dort enthaltenen Informationen zu unterbinden.
Addendum: Microsoft hat in CVE-2021-36934 den nachfolgenden Befehl als Workaround angegeben (habe ich die Nacht überlesen oder er ist nachgetragen worden):
icacls %windir%\system32\config\*.* /inheritance:e
Verändert die Zugriffsrechte auf den Ordner, wie auch nachfolgend diskutiert wird.
Mark Heitbrink weist in nachfolgendem Kommentar berechtigt darauf hin, dass die Zugriffsberechtigungen in verwalteten Umgebungen per Gruppenrichtlinien erfolgen soll. Das Ganze findet sich unter Computerconfiguration -> Richtlinien -> Windows-Einstellungen -> Sicherheitseinstellungen -> Dateisystem. Auf gruppenrichtlinien.de findet sich dieser Artikel zum Thema. Danke an Mark für den Hinweis.
Ähnliche Artikel:
Windows 10: SAM-Zugriffsrechte ab 1809 nach Upgrade kaputt, Benutzerzugriff möglich
PrintNightmare: Point-and-Print erlaubt die Installation beliebiger Dateien
Anzeige
Können wir die Berechtigungen bitte mit Gruppenrichtlinien setzen?
Computer Konfiguration\…\Lokale Richtlinien\Dateisystem
Mark, immer gerne. Vorschlag: Nimm einen Artikel in gruppenrichtlinien.de auf. Wenn Du mir den Link schickst, binde ich den hier ein. Danke.
Wenn ich mir die Rechte ansehe, befindet sich auch der TrustedInstaller darunter. Wenn ich eine GPO bezüglich Berechtigungen erstelle fehlt mir jedoch genau dieser, abgesehen davon, dass der wieder spezielle Berechtigungen hat.
Jemand eine Idee was passiert wenn man den TrustedInstaller also via GPO inherited vom Ordner fetzt?
das löschen der Benutzer mit icacls sollte vor allem auch in den Installationsimages erfolgen …
damit haben spätere Neuinstallationen den Fehler von Anfang an nicht !
Moin,
hab jetzt mal bei meinem Domänen-Client (Windows 10 21h1) geschaut und folgende Rechte sind auf den Dateien:
SYSTEM – Vollzugriff
lokale Administratoren-Benutzergruppe – Vollzugriff
mein Domänen-User-Account – Vollzugriff
sonst keine Berechtigungen drin.
GPO haben wir hierzu nichts gemacht
Schöne Grüße
Sebastian
Moin,
das mit dem eigenen Benutzer dürfte daran liegen, dass man mit dem Windows-Explorer auf den Ordner config zugegriffen hat.
Da folgt dann eine UAC-ähnliche Abfrage, ob dauerhaft Zugriff gewährt werden soll: https://imgur.com/Q5XTlSr
MfG
Stephan
Sehe ich auch so – daher mein Tipp in den Kommentaren des vorherigen Artikels, einen portablen Dateimanager statt des Explorers (der ja Bestandteil der Shell ist, und die Zugriffsrechte verändert) zur Kontrolle einzusetzen. Oder man kontrolliert in der Eingabeaufforderung.
Noch besser ist STRIKTE Benutzertrennung, d.h. das bei der Installation angelegte "vernarrenkappte" Administratorkonto zu einem Standardbenutzerkonto zu machen und ALLE administrativen Aktionen NUR im (aktivierten) ECHTEN Administratorkonto durchzuführen: dort macht der Explorer NICHT den in https://support.microsoft.com/en-us/kb/950934 dokumentierten Blödsinn!
Siehe auch https://skanthak.Homepage.t-online.de/slipstream.html#finalisation
sowie
https://skanthak.Homepage.t-online.de/SAFER.html
Moin,
also es ist bei uns so:
An den Clients ist der lokale Admin standardmäßig deaktiviert.
wenn ich über Admin-CMD die Berechtigung checke kommt das raus:
C:\Windows\System32\config>icacls sam
sam NT-AUTORITÄT\SYSTEM:(I)(F)
VORDEFINIERT\Administratoren:(I)(F)
Domain\_meinuser_:(I)(F)
1 Dateien erfolgreich verarbeitet, bei 0 Dateien ist ein Verarbeitungsfehler aufgetreten.
Bin jetzt hier grad nicht so firm … wäre das jetzt soweit ok?
Sieht zumindest aus wie wenn ich es über den Explorer prüfen würd?
Schöne Grüße
Sebastian
Sebastian, wenn du sicher bist, dass auf allen Workstations das so ist, dann hast du Glück gehabt. Es schadet nichts, die Rechte überall nochmal richtig zu setzen, auch wenn sie es schon sind. So erwischst du halt auch die, wo du nicht nachgesehen hast.
Da habe ich auf Windows 7 über die Jahre sicher bei etlichen Ordnern die Berechtigungen durch den Explorer ungewollt dauerhaft geändert und absolut keinen Überblick darüber.
Ein komplettes Zurücksetzen mit
icacls c:\* /reset /t /c /q
ist mir aber zu gefährlich. Das würde sicherlich Kollateralschäden nach sich ziehen.
Wie konnte Microsoft überhaupt auf die Idee kommen, den Explorer da dauerhafte Änderungen vornehmen zu lassen? :(
Ich habe stichprobenweise auf verschiedenen Win 10 PCs in der Domäne nachgesehen und fand mal solche, mal solche. Nur bei 20H2 fand ich es nicht, beiu 1909 und 21h1 aber größtenteils schon.
Ich finde den Microsoft-Vorschlag
icacls %windir%\system32\config\*.* /inheritance:e
besser, da er die Zugriffsrechte aller Dateien im Ordner config mit denen des Ordners ersetzt/vererbt. Wer weiß, was da noch für Leichen im Keller liegen…
Und dann noch alte Schattenkopien löschen und einen neuen Wiederherstellungspunkt erstellen, und dann dafür sorgen, dass alle Clients im AD das einmalig bekommen, und auch neu aufgesetzte Clients das automatisch einmal bekommen.
Bei mir hat icacls %windir%\system32\config\sam /remove „Users" & Co in einer ADMIN CMD nicht gegriffen,
sehr wohl aber icacls %windir%\system32\config\*.* /inheritance:e.
Ist damit für mich der sichere Weg, den ich auch per Script ausrollen werde.
Kopfzerbrechen macht aber noch das vssadmin Problem mit Defender.
Hat da schon wer eine Lösung?
Hab gerade noch eine frisch aufgesetzten Server 2019 kontrolliert – dort ist das Problem nicht vorhanden – also für die Server eine vorsichtige Entwarnung…
Liegt wohl daran, dass in einem deutschen Windows 10 statt „Users" „Benutzer" angegeben werden muss. Wer das in einem internationalen Konzern umsetzen muss, nimmt besser die Well-known-SID "S-1-5-32-545", die ist überall gleich. Aber am Besten ist der Befehl, der von Microsoft empfohlen wird:
icacls %windir%\system32\config\*.* /inheritance:e
Der wendet das nämlich auf alle Dateien in dem Verzeichnis an, auch auf Unterordner. Denn wer weiß, was da noch für Leichen im Keller liegen.
Ps: Neuer Chrome ist da, bisher nooch ohne jegliche Erwähnung in den Release Notes.
"Users" hatte ich mit "Benutzer" ersetzt – hat trotzdem nicht funktioniert. SID hab ich dann nicht mehr probiert weil besser gleich das ganze Verzeichnis beackern, "denn wer weiß, was da noch für Leichen im Keller liegen".
Damit löscht man aber mehr, als nur die Benutzer-Gruppe. Mal sehen, ob das wieder nach hinten losgeht, bei PrintNightmare gab es ja erstmal ähnliche Workarounds.
nochmal: wenn du das im Installationsimage fixt, mußt du dich nicht um neu aufgesetzte Clients kümmern und kannst das nicht vergessen …
Ja, auch eine gute Idee. Ich habe ein Startup-Script gebastelt, was nach Erledigung der Schritte einen Reg-Key setzt, und wenn das Script wieder läuft, und den Reg-Key findet, dann macht es nix. Es erkennt auch Server und macht auch da nix.
Oh Gott, was für ein Gefrickel. Viel Spaß mit dem Müllsystem :-)
Viel Spaß beim Kernelpatchen! Und Systemd. Beides gerade angreifbar. Lücken waren 6 bzw. 7 Jahre offen! Linux – von Amateuren für Amateure.
1. es geht hier nicht um Linux, sondern um den MS Müll
2. Linux als Amateursystem bezeichnen und Windows nutzen bzw 24 Stunden am Tag dran herum frickeln – kannste Dir nicht ausdenken, ymmd :-D
Schön, dass du erkannt hast, dass es hier nicht um Linux geht. Warum bist du dann hier? Deine Anfeindungen wurden neulich schonmal hier gelöscht.
Hier feindet nur einer und bist du. Bist du so überfordert mit der Materie?
Otto, was sagst du rückblickend zu deinem Beitrag von 21. Juli 2021 um 11:46 ???
Ich würde sagen, unqualifizierter Müll, der niemanden weiter bringt.
Seien wir doch lieber froh, dass wir uns mit einfachen Skripten selber helfen können.
@Otto: Bitte abrüsten – ich hatte den Kommentar mal freigeschaltet – aber die Diskussion Windows versus Linux sollte hier in den Kommentaren definitiv beendet werden. Bringt keinen Admin einen mm weiter. Danke für das Verständnis.
Moment, wo gäbe ich was von Linux geschrieben?
Ich habe lediglich gesagt, was Windows in diesem Zustand und was MS da treibt, ein Müllsystem ist. Die Linux-Diskussion inkl dem üblichen Fanboywahaboutism und persönlichwe Angriffe hat wieder mal(!) Kollege 1ST1 vom Zaun gebrochen. Vielleicht sollte man daieber Mal aufräumen. Oder hat der hier nen Freibrief?
Schöne Grüße
@Otto: Es bringt einem Windows-Admin nichts, wenn jemand auf Linux als bessere Alternative verweist. Der muss schlicht seinen Job erledigen und die Windows-Systeme sicher am Laufen halten. Das zu unterstützen, ist Sinn und Zweck der Blog-Beiträge hier.
Wenn ich bei Windows ins Feuer blase, ist das gut zu erkennen. Da könnte man schon mal einen Kommentar dahingehend "ich finde Linux besser" einstellen – sollte aber Substanz haben.
Im Gegenzug hilft es einem Linux-Nutzer/Administrator wenig, wenn er gesagt bekommt, dass es da ja auch Schwachstellen gibt.
Führt diese Diskussionen im heise-Forum oder unter Beiträgen hier im Blog, wo ich gegen Windows stänkere.
Aber in Blog-Beiträgen, wo es um konkrete Probleme geht, solche Diskussionen vom Zaum zu brechen, halte ich für kontraproduktiv (ich drücke es mal freundlich aus – gilt für alle Seiten), und ist für die mitlesenden Admins, die sich über Fragestellungen oder Sachverhalte zum gegenständlichen Problem informieren möchten, schlicht ätzend. Der gesamte Thread ab deinem Eingangskommentar enthält Null Information, was das im Beitrag angesprochene Problem betrifft.
Ich hoffe immer noch darauf, dass diese Idee "die Admins helfen sich gegenseitig und ergänzen meine Blog-Beiträge mit weiterführenden Kommentaren" weiterhin umgesetzt und nicht durch ein oder zwei Leute, die sich hier beharken, gekillt wird.
Ich zensiere ungerne – einen deiner letzten Beitrag habe ich wegen persönlichen Beharkens in SPAM einsortiert. Ich lasse den Diskussionsthread mal stehen und lösche (noch) nicht – in der Hoffnung, dass jetzt Ende dieser Diskussion ist.
Bisher läuft dieser Blog 14 Jahre, in denen ich 2 oder 3 Nutzer bannen musste. Ich würde ungerne einen Bann für dich einrichten – werde das aber tun, wenn die Gefahr besteht, dass durch dieses Beharken der Blog gekillt wird. Du sprachst 1ST1 an – manches mag ich zwar auch nicht, aber zumindest kommen zu 90% zielführende Informationen für die Mitleser von ihm. Da nehme ich durchaus in Anspruch abzuwägen, "Meinung" ggf. zu ignorieren (läuft sich dann tot), und die Perlen dankbar im Blog aufzunehmen.
Danke für dein Verständnis.
Können wir noch einmal über Gruppenrichtlinien reden?
Siehe Artikel. Die Besonderheit der CSE Security DLL ist, das sie unabhängig von der Version der Richtlinie alle 16 Stunden erneut angewendet wird. Deine ACLs werden zur Not immer wieder korrigiert.
siehe auch:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\GPExtensions\{827D319E-6EAC-11D2-A4EA-00C04F79F83A}
MaxNoGPOListChangesInterval=960 (Minuten)
… scripting, Igitt :-)
icacls %windir%\system32\config\sam /remove „Users"
icacls %windir%\system32\config\security /remove „Users"
icacls %windir%\system32\config\system /remove „Users"
Funktioniert nur auf englischen Systemen, ergo: schlechte Idee.
Besser:
icacls %windir%\system32\config\sam /remove *S-1-5-32-545
icacls %windir%\system32\config\security /remove *S-1-5-32-545
icacls %windir%\system32\config\system /remove *S-1-5-32-545
Noch besser ist, den Kommandoprozessor icacls NICHT in .;%PATH% alias %CD%;%PATH% suchen zu lassen:
%SystemRoot%\System32\ICACLs.exe …
Siehe CWE-471 alias "path order hijacking"
Bei Spielkindern, die noch immer statt eines STANDARD-Benutzerkontos das bei de Installation angelegte vernarrenkappte "Administrator"-Konto missbrauchen, in dem der Explorer auf (automatische) Nachfrage die Zugriffsrechte nicht-beschreibbarer Verzeichnisse versaubeutelt, beugt ein
%SystemRoot%\System32\Attrib.exe +H +S %SystemRoot%\System32\Config
Letzterem vor (gilt selbstverständlich auch für %SystemRoot%\Temp\)
Siehe https://support.microsoft.com/en-us/kb/950934
Und wenn der Hacker vorher %systemroot% verbogen hat?
Hallo zusammen
icacls %windir%\system32\config\sam /remove „Users"
icacls %windir%\system32\config\security /remove „Users"
icacls %windir%\system32\config\system /remove „Users"
passt für englische Systeme.
Es müssen die stilistischen „" durch normale " "ersetzt werden.
In Deutsch wäre es dann
icacls %windir%\system32\config\sam /remove "VORDEFINIERT\Benutzer"
icacls %windir%\system32\config\security /remove "VORDEFINIERT\Benutzer"
icacls %windir%\system32\config\system /remove "VORDEFINIERT\Benutzer"
Hab mir soeben das install.wim vom 20H2 Pro/Ent iso angesehen:
Dort gibt es den Benutzer NICHT! Das erklärt auch die Aussagen dazu.
Bei uns scheinen 20H2 Pro Installationen auch nicht betroffen zu sein.
Wir haben für das Imaging das offizielle Iso aus dem VLSC verwendet. Der integrierte Patchstand müsste Januar 2021 gewesen sein (bin mir aber nicht sicher).
ISO Name: SW_DVD9_Win_Pro_10_20H2.3_64BIT_German_Pro_Ent_EDU_N_MLF_-2_X22-50334.ISO
tja windows 10 21h1 hab ich weder in der firma auf enterprise noch privat auf pro das problem. ebenso hab ich mal einen unserer server 2019 (sind ja build 1809) gecheckt. da tritt es auch nicht auf.
kann das sein, dass das problem nur existiert wenn bestimmte software installiert wurde, die ggf. das modifiziert?
Server sind generell nicht betroffen. Der Fehler steckt in der install.wim auf der Installtions-ISO von Windows 10 1809 bis 21h1 und Windows 11. Die 20H2 ist "seltsammerweise" scheinbar nicht betroffen, vielleicht gibt es da verschiedene ISOs.
ich hab hier maschinen mit 1909 bzw. 2004 prof und 2004 enterprise installiert und dann mit jedem feature update auf 21h1 hochgezogen. auf keiner dieser maschinen ist das problem vorhanden.
wobei ich sagen muss. die enterprise isos kamen vom vlsc Portal, das win 10 pro wurde extra mit mac als iso geladen und nicht mit media creation tool erzeugt.
insofern da nicht irgendein update nicht wieder was repariert hat, dürfte ich saubere isos gehabt haben.
vielleicht werden die medien ja mit dem media creation tool "kaputt" erzeugt
hab mir jetzt von https://www.microsoft.com/de-de/software-download/windows10ISO die aktuelle deutsche win1021h1 64bit iso geladen.
hash: Deutsch 64-bit CF0DB565A3B186703C244C9B20A1B706020A117F77349A97DF0F2EDC82D10F30
die install.wim auf diesem iso hat erstellungsdatum 9..4.2021 16:52
mounte ich dieses und prüfe bspw. die acl von c:\windows\system32\config\SAM über explorer nach UAC bestätigung. So sind hier keine Standard User berechtigt. Nur System und Administratoren bzw. mein User jetzt wegen UAC bestätigung.
Keine Ahnung was man tun muss um ein "kaputtes" Medium zu erhalten.
Im 21h1 iso X22-55042 gibt es den Benutzer in den Zugriffsrechten …
Unser Antivirus-Client findet
vssadmin delete shadows /all /quiet
überhaupt nicht lustig…
Das klappt bei mir auch nicht richtig.
vssadmin delete shadows /all /quiet
kann man ohne Fehler ausführen.
Es wird aber nichts gelöscht! Erst ein Start ohne die /quiet Option und dem anschließenden Bejahen der Nachfrage, ob gelöscht werden soll, macht es dann tatsächlich. Hat das noch jemand? Version 20H2
Hallo zusammen,
ich habe versucht
vssadmin delete shadows /all /quiet
als cmd via SCCM-Paket zu verteilen. Das Skript-Paket wird erfolgreich ausgeführt, die VolumeShadowCopies bleiben aber leider vorhanden. Wenn dort jemand eine Lösung zu hat, wäre ich sehr daran interressiert. Hier ist ebenfalls der Defender (MS Endpoint Protection) im Einsatz.
Die acls auf sam, security und system habe ich via helge klein's freeware tool SetACL tool korrigiert. Da verschiedensprachige clients eingesetzt werden, war die Nutzung der SID der sauberere weg.
setacl -on "c:\windows\system32\config\sam" -ot file -actn trustee -trst "n1:S-1-5-32-545;ta:remtrst;w:d,s"
setacl -on "c:\windows\system32\config\ssystem" -ot file -actn trustee -trst "n1:S-1-5-32-545;ta:remtrst;w:d,s"
setacl -on "c:\windows\system32\config\security" -ot file -actn trustee -trst "n1:S-1-5-32-545;ta:remtrst;w:d,s"
Zu Jens und Shirkan:
Ich habe einen immediate Task genutzt, um es per Group Policy preference zu verteilen.
Executor: System.
Task Action: vssadmin
Task action parameters: delete shadows /all /quiet
Ergebnis geprüft: Shadowcopies wurden gelöscht.
vssadmin delete shadows /all ist im Zusammenhang mit der Option /quiet nicht vorgesehen..also nicht wundern, wenn das via CMD erstmal nichts löscht
siehe Microsoft Hilfe:
C:\WINDOWS\system32>vssadmin delete shadows /?
vssadmin 1.1 – Verwaltungsbefehlszeilenprogramm des Volumeschattenkopie-Dienstes
(C) Copyright 2001-2013 Microsoft Corp.
Delete Shadows /For=FürVolumespec [/Oldest] [/Quiet]
Delete Shadows /Shadow=Schattenkopienkennung [/Quiet]
Delete Shadows /All
– Löscht alle für "FürVolumespec" übereinstimmenden Schattenkopien.
Löscht die älteste Schattenkopie auf dem Volume, wenn /Oldest angegeben
wird. Löscht alle löschbaren Schattenkopien auf allen Volumes, wenn /All
angegeben wird. Bei /Shadow=Schattenkopienkennung wird die Schattenkopie
mit dieser Schattenkopienkennung gelöscht. Es können nur Schattenkopien
vom Typ "ClientAccessible" gelöscht werden.
– Verwenden Sie den Befehl "List Shadows", um die Schattenkopiekennung
anzuzeigen. Eine Schattenkopiekennung muss das folgende Format haben:
{XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX}
(X steht für Hexadezimalzeichen.)
Beispielsyntax: vssadmin Delete Shadows /For=C: /Oldest
Ach, äh, Garfield. Wenn Microsoft im Spiel ist, ist meistens austesten angesagt, um sicher zu gehen. Machen wir das:
—————————————–
C:\WINDOWS\system32>vssadmin list shadows
vssadmin 1.1 – Volume Shadow Copy Service administrative command-line tool
(C) Copyright 2001-2013 Microsoft Corp.
Contents of shadow copy set ID: {8d28dd98-4578-4614-86aa-895b3b06d638}
Contained 1 shadow copies at creation time: 05.08.2021 13:33:38
Shadow Copy ID: {95142c8e-a3be-4c38-8a30-f3c28e1f7667}
Original Volume: (C:)\\?\Volume{390f728a-b383-4300-8a46-a505120ab047}\
Shadow Copy Volume: \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1
Originating Machine: xxx.xxx.de
Service Machine: xxx.xxx.de
Provider: 'Microsoft Software Shadow Copy provider 1.0'
Type: ClientAccessibleWriters
Attributes: Persistent, Client-accessible, No auto release, Differential, Auto recovered
C:\WINDOWS\system32>vssadmin delete shadows /all /quiet
vssadmin 1.1 – Volume Shadow Copy Service administrative command-line tool
(C) Copyright 2001-2013 Microsoft Corp.
C:\WINDOWS\system32>vssadmin list shadows
vssadmin 1.1 – Volume Shadow Copy Service administrative command-line tool
(C) Copyright 2001-2013 Microsoft Corp.
No items found that satisfy the query.
——————————————-
qed