HiveNightmare: Neue Details zur Windows-Schwachstelle CVE-2021-36934

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

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.


Anzeige

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


Cookies blockieren entzieht uns die Finanzierung: Cookie-Einstellungen

Anzeige


Dieser Beitrag wurde unter Sicherheit, Windows 10 abgelegt und mit Sicherheit, Windows 10, Windows 11 verschlagwortet. Setze ein Lesezeichen auf den Permalink.

44 Antworten zu HiveNightmare: Neue Details zur Windows-Schwachstelle CVE-2021-36934

  1. Mark Heitbrink sagt:

    Können wir die Berechtigungen bitte mit Gruppenrichtlinien setzen?
    Computer Konfiguration\…\Lokale Richtlinien\Dateisystem

    • Günter Born sagt:

      Mark, immer gerne. Vorschlag: Nimm einen Artikel in gruppenrichtlinien.de auf. Wenn Du mir den Link schickst, binde ich den hier ein. Danke.

    • Markus K sagt:

      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?

  2. jup sagt:

    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 !

  3. Sebastian sagt:

    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

    • Stephan sagt:

      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

      • Günter Born sagt:

        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

          • Sebastian sagt:

            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

          • 1ST1 sagt:

            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.

      • Martin sagt:

        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? :(

    • 1ST1 sagt:

      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.

  4. 1ST1 sagt:

    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.

    • Karl sagt:

      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…

      • 1ST1 sagt:

        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.

        • Karl sagt:

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

    • riedenthied sagt:

      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.

  5. jup sagt:

    nochmal: wenn du das im Installationsimage fixt, mußt du dich nicht um neu aufgesetzte Clients kümmern und kannst das nicht vergessen …

    • 1ST1 sagt:

      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.

      • Otto sagt:

        Oh Gott, was für ein Gefrickel. Viel Spaß mit dem Müllsystem :-)

        • 1ST1 sagt:

          Viel Spaß beim Kernelpatchen! Und Systemd. Beides gerade angreifbar. Lücken waren 6 bzw. 7 Jahre offen! Linux – von Amateuren für Amateure.

          • Otto sagt:

            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

          • 1ST1 sagt:

            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.

          • Otto sagt:

            Hier feindet nur einer und bist du. Bist du so überfordert mit der Materie?

          • 1ST1 sagt:

            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.

        • Günter Born sagt:

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

          • Otto sagt:

            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

          • Günter Born sagt:

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

      • Mark Heitbrink sagt:

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

  6. Bernhard Diener sagt:

    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

  7. Reto Felix sagt:

    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“

  8. jup sagt:

    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.

  9. Phatair sagt:

    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

  10. MOM20xx sagt:

    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?

    • 1ST1 sagt:

      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.

      • MOM20xx sagt:

        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

        • MOM20xx sagt:

          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.

  11. jup sagt:

    Im 21h1 iso X22-55042 gibt es den Benutzer in den Zugriffsrechten …

  12. PCP sagt:

    Unser Antivirus-Client findet

    vssadmin delete shadows /all /quiet

    überhaupt nicht lustig…

  13. Jens Faßbender sagt:

    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

  14. Shirkan sagt:

    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“

  15. Bernhard Diener sagt:

    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.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.

Hinweis: Bitte beachtet die Regeln zum Kommentieren im Blog (Erstkommentare und Verlinktes landet in der Moderation, gebe ich alle paar Stunden frei, SEO-Posts/SPAM lösche ich rigoros). Kommentare abseits des Themas bitte unter Diskussion.