[English]Administratoren lassen Windows mittels einer unattend.xml-Datei installieren und einrichten. Die Datei unattend.xml lässt sich mit einem Generator erstellen. Ein Blog-Leser hat mich bereits im Juli 2025 darauf hingewiesen, dass unter Windows 11 24H2 aber bei Verwendung einer unattend.xml ein Sicherheitsproblem entsteht.
Was sind Antwortdateien (unattend.xml)?
Windows lässt sich über Antwortdateien (unattend.xml) unbeaufsichtigt installieren und in den Voreinstellungen konfigurieren. Es handelt sich um .xml-Dateien, die die Anweisungen zur unbeaufsichtigten Installation enthalten. Windows Setup sucht an bestimmten Speicherorten automatisch nach Antwortdateien, oder Administratoren können eine zu verwendende Datei für die unbeaufsichtigte Installation angeben, indem die Option /unattend: beim Ausführen von Windows Setup (setup.exe) verwendet wird.
Eine vollständige Liste der Einstellungen für die Antwortdatei (auch als Einstellungen für die unbeaufsichtigte Installation bezeichnet) finden Sie in der Referenz für die unbeaufsichtigte Windows-Installation.
Ein Generator für Antwortdateien
Christoph Schneegans hat einen Generator zur Erzeugung unattend.xml-Dateien im Internet unter Generate autounattend.xml files for Windows 10/11 bereitgestellt.
Dort lassen sich die gewünschten Parameter für die Windows-Installation interaktiv in Formularen auswählen und die Datei unattend.xml generieren.
Windows 11 24H2: Sicherheitsproblem durch unattend.xml
Ein Blog-Leser hatte mich Mitte Juli 2025 per E-Mail kontaktiert und wies auf Sicherheitsproblem durch unattend.xml bei Windows 11 24H2 hin, auf das er gestoßen ist. Er schrieb mir dazu: "Ich melde mich nun bei Ihnen, um (falls noch nicht bekannt) auf einen meiner Meinung nach kritischen Umstand aufmerksam zu machen, welcher vor allem Unternehmen betrifft."
Es geht um das Verhalten einer Windows 11 24H2-Installation, wenn diese per unattend.xml, sprich automatisiert durch Deploymenttool XYZ durchgeführt wird. Seit Windows 11 24H2 werden nach der Installation unter:
C:\Windows\Panther\
zwei Kopien dieser unattend.xml abgelegt, schrieb der Leser. Das Problem ist, dass die "unattend.xml" den bei der Installation erstellten Administrator-Benutzernamen im Klartext enthält (was laut Leser bereits schlimm genug ist, da für den lesenden Zugriff auf diese Datei keine Administratorrechte nötig sind).
Der Leser schrieb, dass bei der Installation oftmals der "Builtin"-Administrator nach MS Best Practice durch eine unattend.xml deaktiviert wird. Gleichzeitig wird ein Konto für einen lokalen Administrator erstellt.
Der Name dieses Administrator-Kontos taucht dann in der Datei unattend.xml auf. Weiterhin enthält die zweite gespeicherte "unattend-original.xml"-Datei neben dem lokalen Administrator-Namen auch dessen Kennwort im Klartext.
Das bedeutet: Unternehmen, welche Clients automatisiert mit Windows 11 24H2 aufsetzen und das Kennwort des lokalen Administrators NICHT z.B. per LAPS ändern bzw. individualisieren, haben unter C:\Windows\Panther\ eine Blaupause für die Verbreitung eines Wurms oder Schlimmerem liegen.
Die offensichtliche Lösung an dieser Stelle: Löschen dieser beiden Dateien per Softwareverteilungstool/GPO. Der Leser schrieb: Sucht man im Internet nach "unattend-original.xml", so findet man derzeit nur sehr wenig Material, sodass ich mir nicht sicher bin, inwiefern dieses Thema bereits "Kreise zieht". Ich habe die Information daher mal hier im Blog eingestellt – danke an den Leser für den Hinweis.
MVP: 2013 – 2016
Das lokale Admin Passwort aus der Antwortdatei wird von mir seit je her nach dem Deployment automatisch geändert, sobald der PC die Domain betritt. Ebenso das Passwort der Fernwartungssoftware, die für ein ersten direkten Fernzugriff über die Antwortdatei schon mitinstalliert wird. Für mich ist schon die Existenz der Datei selber im Deployment ein mögliches Risiko, daher sind die Maßnahmen hier schon bedacht.
Es stellt mir sich jetzt aber die Frage ob man der Schneegans Generator im letzten Schritt des Deployments die Datei nicht theoretisch selber löschen könnte.
Im allerletzte Schritt kann man eigenen Setups und Batch Dateien ausführen lassen, die in den $$ Verzeichnissen abgelegt sind und beim ersten Start von Windows ausgeführt werden. Ich glaube zu dem Zeitpunkt ist die Antwortdatei mit ihrer Arbeit schon durch.
Wenn das geht, danke für die Warnung, aber besser wäre es das mit in den Generator als Option einzubauen.
Gerate mal bei einem frischen, direkt mit 24H2 fertig gemachten PC nachgeschaut. Ich kann die angesprochenen Dateien nicht in dem Pfad oder Unterordnern finden.
Bei uns ist Configuration Manager im Einsatz, wir löschen da auch nichts explizit. Bei uns wird das Passwort für den Standard-Administrator nach dem Beitritt in die Domäne durch LAPS automatisch geändert.
Eventuell hängt es vom eingesetzten Deployment-Tool ab?
Hallo zusammen, ich habe mir die unattend.xml bei uns hier näher angeschaut.
Ein Kennwort wird hier nicht angezeigt…
*SENSITIVE*DATA*DELETED*
Eine automatische Antwortdatei lassen wir hier aber auch nicht generieren, braucht es meiner Meinung aber auch nicht unbedingt. Das meiste wird dann über die GPOs aktiviert/aktualisiert, da die PCs während des Deployments in die Domäne aufgenommen werden. Domäne, Zeitzone usw. wird außerhalb der unattend.xml bereits geregelt, genauso wie die zu installierenden Programme.
Unser Deployment wird über das Microsoft Deployment Toolkit (MDT) realisiert, das installierte BS ist natürlich Win11 24H2.
MfG
Robert
In der unattend.xml ja, aber in der darunter liegenden unattend-original.xml ist das PW nicht durch *SENSITIVE*DATA*DELETED* ersetzt.
Gruß
@Chris
eine unattend-original.xml gibt es bei mir nicht..
-es ist wirklich die einzige unattend.xml Datei die hier vorhanden ist, keine versteckte Datei usw.
Gruß ;)
Mehrfach bei uns probiert. Es ist dasselbe Verhalten wie bei Robert. Es gibt eine unattend.xml wo kein Passwort enthalten ist. Eine unattend-original.xml ist nicht verfügbar.
MDT erfolgreich und Bestätigungsfenster abgeschlossen. Aber es scheint, die unattend-original.xml kann zeitweise automatisch durch Windows entfernt werden – sofern doch noch vorhanden. Zumindest findet man Hinweise drauf…
Hier keine (!) *unattend*.XML Datei gefunden in c:\windows\panther
da kann also nix aufgedeckt werden,
Deployment war über USB mit autounattend.xml aufm Stick.
Wie groß ist deine Stichprobe? Ich nehme an: ein einziger Computer. Also sicherlich eine relevante Größe für definitive Aussagen.
:-D
> Seit Windows 11 24H2 werden nach der Installation unter:
> C:\Windows\Panther\
> zwei Kopien dieser unattend.xml abgelegt.
Das kann ich nicht bestätigen. Es ist wohl eher eine Kombination aus der Art der Verteilung und des genutzten Editors zur Erstellung der XML.
Wer die XML mit dem WISM erstellt, erhält in der XML ein verschlüsseltes Kennwort. Jegliche Generatoren und Editoren erzeugen Plaintext. WISM ist sicherlich umständlich in der Anwendung, aber sollte wenigstens für das Kennwort Feld verwendet werden. Man kann ja eine vorhandene XML damit öffnen.
Per MDT verteilt existiert KEINE unattend-orginal.xml und das verschlüsselte Kennwort ist durch den Platzhalter *SENSITIVE*DATA*DELETED* ersetzt
danke für den Einwurf, Du könntest Recht haben. Ich kontaktiere nochmals den Einsender, um die Frage anzusprechen.
Das ist aber doch auch nur base64 "verschlüsselt", oder?
Richtig, bestenfalls eine Verschleierung, keine Verschlüsselung. WSIM nimmt das Passwort, hängt den String „Password" hinten dran und transformiert das ganze nach Base64. Für das Passwort „geheim" wird bspw. der Wert „ZwBlAGgAZQBpAG0AUABhAHMAcwB3AG8AcgBkAA==" generiert.
Ja, Jein, vielleicht? :-)
Das Plaintext Kennwort "123" wird als "UABhAHMAcwB3AG8AcgBkAA==" gespeichert, das aber als "Password" decodiert wird.
es ist nicht so komplex, wie es sein sollte und man es gerne hätte
verschlüsselt ist es, weil zum simplen Umrechnen/Encoding ein Geheimnis kommt, somit ist es methodisch verschlüsselt.
das das Geheimnis trivial "Password" ist, ist ein anderes Problem.
auf dem ersten Blick wird ein normaler Anwender damit nichts anfangen können.
Betr. "erhält in der XML ein verschlüsseltes Kennwort.":
Verschlüsselt womit?
verschlüsselt mit einem veröffentlichten nachvollziehbaren Umrechnungsweg (base64) plus einem festhinterlegtem Secret (Passwort) das den beteiligten Komponenten/Prozessen bekannt ist
Ich dachte Sie gelten in Deutschland als Windows-Koryphäe, da bleibt mir bei Ihrer unbekümmerten Antwort dann doch die Spucke weg. Wollen Sie 's nochmal versuchen?
Wie ein anderer Forist bereits anmerkte, Base64 (1) ist Encoding nicht Encryption! Das ist keine Sophisterei sondern Wiederholung von Grundlagen der Fachinformatiker-Ausbildung.
Betr. "plus einem festhinterlegtem Secret (Passwort) das den beteiligten Komponenten/Prozessen bekannt ist":
Das ist mir im Aussagegehalt zu dürr und wohl auch Unsinn. Dieses vermeintliche Secret ist vermutlich verglichen bspw. mit unter C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys gespeicherten Schlüsseln mit keinerlei Schutz gegen unbefugtes Aufdecken versehen.
_
(1) https://datatracker.ietf.org/doc/html/rfc4648
https://learn.microsoft.com/en-us/windows-hardware/customize/desktop/unattend/microsoft-windows-shell-setup-useraccounts-localaccounts-localaccount-password-plaintext
Das verwendete Passwort im Beispiel XML ist passwordPassword.
Das "Password" ein zusätzliches Geheimnis ist und man es "wegkürzen" muss, muss man wissen. Am Ende hat MS zu Vista Zeiten vor 20 Jahren gedacht, das es ausreichend ist. Vor allem, weil sie das Kennwortfeld bis zur 24H2 zumindest aus der Datei entfernt haben, bzw. überschrieben haben.
Beim MDT stehts mit drin. c:\windows\panther\unattend.xml
doof ^^
Also bei uns gibts nur die unattend.xml unter C:\Windows\Panther – keine unattend-original.xml. Passwort ist ersetzt durch *SENSITIVE*DATA*DELETED* (wobei das nach der Erstinstallation eh erstmal leer ist und dann per LAPS festgelegt wird). Und der BUILTIN\Administrator bleibt bei uns auch deaktiviert, so wie es sein soll.
Wenn alles ohne Fehler bis zum Ende läuft steht da nichts mehr.
Es kann aber einiges bis dahin passieren und schief gehen und dann hat man halt Zombis. Wo auch immer. Z. B. auch in den Ordnern %SYSTEMDRIVE%\$WINDOWS.~*.
Passwörter gehören deshalb nicht in *unattend.xml, setupconfig.ini oder andere temporäre Dateien, die nur beim Setup einmalig ausgeführt und hoffentlich danach gelöscht werden.
Mehr als darauf hinweisen, dass selbst "verschlüsselte" Passwörter in *unattend.xml nur verschleiert werden kann Schneegans aber nicht. Standardmäßig ist das ja auch deaktiviert und das Script richtet sich nicht an absolute Laien.
Ich setze das Password in unattend.xml immer erst einmal auf leer. Im Verlauf des weiteren Erstsetups wird das Passwort dann entweder zum individuellen Setzen abgefragt oder beim Domänenbeitritt/MS SSO automatisch gesetzt.
Ist das Passwort dann -egal für welchen User- bei der Ersteinrichtung eines Acounts immer noch leer wird durch eine systemmodalen Dialogbox aus einem RunOnce Script darauf hingewiesen wie man es mittels Strg+Alt+Entf (bzw. Ende+Alt+Entf aus einer VM) jetzt gefälligst erstmalig setzt/ändert.
Macht man auch das dann nicht wird man durch ein System Tasksheduler Script nach 15 Minuten wieder zwangsausgeloggt.
Dieses Spielchen wiederholt sich bis ein lokales Passwort gesetzt ist. Erst dann löscht sich dann das Tasksheduler Script selbst.
Wenn Windows Setup (setup.exe) unter Windows PE ausgeführt wird und eine Antwortdatei verwendet, kopiert es diese als \Windows\Panther\unattend.xml und \Windows\Panther\unattend-original.xml auf die Zielpartition, damit die unbeaufsichtigte Installation nach dem Reboot fortgesetzt werden kann. Das passiert keineswegs erst ab Windows 24H2, sondern mindestens seit Windows 10. Etwa https://schneegans.de/windows/unattend-generator/usage/#security weist auch genau darauf hin.
Das eingebaute Benutzerkonto „Administrator" wird auch nicht durch die Antwortdatei *deaktiviert* – es ist ja bereits standardmäßig inaktiv. Eine Antwortdatei kann dieses Konto vielmehr *aktivieren*.
Ich muss mich korrigieren: \Windows\Panther\unattend.xml gab es immer schon, \Windows\Panther\unattend-original.xml in der Tat erst ab 24H2. Das dürfte mit dem neuen „ConX"-Modus von Windows Setup zu tun haben.
@Christoph: Danke für den Hinweis – ich habe das Thema Antwortdateien nie eng verfolgt und erinnerungsmäßig bei Windows 7 mit den SDK-Spielereien aufgehört (ich brauche es nicht für meine zwei Installationen alle 10 Jahre).
ok. somit ist es abhängig vom Deployment Werkzeug, ob die Datei existiert oder nicht. MDT/SCCM verwenden die Setup.exe nur beim Upgrade prozess.
Empirum zb benutzt die .exe zur Erstinstallation
Ich kann das Problem tatsächlich genau so in unserer Umgebung bestätigen. Es scheint aber so, dass Windows das Panther Verzeichnis nach einiger Zeit selbst bereinigt. Bei älteren PCs gibt es nämlich nur noch die unattend.xml im Verzeichnis. Bei ganz frischen Installationen gibt es zusätzlich noch die unattend-original.xml.
"Ein Blog-Leser hat mich bereits im Juli 2025 darauf hingewiesen, dass unter Windows 11 24H2 aber bei Verwendung einer unattend.xml ein Sicherheitsproblem entsteht."
GUTEN MORGÄHN: die [auto]unattend.xml wurde mit Windows Vista vor über 18 Jahren eingeführt, d.h. das vermeintliche Problem ist ALT — eventuell hinterlegte Kennwörter werden seit Windows 7 in der unter %SystemRoot%\Panther\ erstellten Kopie durch *SENSITIVE*DATA*DELETED* ersetzt.
Strunzdummerweise legen die schlampigen Frickler aus Redmond inzwischen auch eine original-unattend.xml an, in der sie die Kennwörter NICHT überschreiben, d.h. die linke Hand des Teufels wusste wieder mal nicht, was die rechte getan hat!
Abhilfe: %SystemRoot%\Panther\original-unattend.xml z.B. per %SystemRoot%\Setup\Scripts\SetupComplete.cmd löschen.
Da fragt man sich, was machen die da beruflich?
Ja das ist mir nach dem Hinweis auch aufgefallen.
Tangiert uns allerdings nur höchst pärifär, da nach dem join LAPS das PW sowieso neu setzt.
Aber ja, da hat Microsoft wieder einmal gute Dienste für manche die es weniger gut mit einem meinen erwiesen,,,
Ich kann das Verhalten unter dem Deployment von Empirum bestätigen. PC´s wurden im Juni mit 24H2 ausgerollt. Also nix mit automatischem Cleanup
Danke für den Hinweis.
Laut Matrix42 wurde das aber in der neuesten Version gefixt
Das "Problem" besteht aber schon seit langem, wir hatten dies auch bei Windows-Server.
Einfach danach die xml-löschen lassen mittels einem Job.
War ja der Zweck des Beitrags – die IT-Mitarbeiter unter der Leserschaft auf das potentielle Problem hinweisen – damit da mit drauf geachtet wird.
Immer dieselbe doof Logik: Was ich schon lange weiß, muss man nicht mehr veröffentlichen…
Wahrscheinlich hast du ein allwissendes Hirn, weil sonst würdest du selbst irgendwann an den Punkt "das ist schon lange bekannt" kommen.
Manche doofen Argumente sterben einfach nie aus.
Danke Günther, dass du wieder einmal darauf hinweist.
Was einmal vorhanden war, bleibt ggf. auch nach Löschen weiter vorhanden und kann theoretisch "recovered" werden. Gar nicht erst speichern ist die einzige echte einfache "davor" Lösung.
iirc kann die unattend auch in anderen Verzeichnissen liegen.
Das kann nervig sein. wenn man die eigentliche Datei unattended.xml genannt hat, weil es so in einem Einführungs Fach Buch steht…
Das Passwort wird nach erfolgreichem Setup ausgeixt.
Kein Passwort zu setzen hatte iirc Nebeneffekte, die man nicht wollte.
Der Account Namens Administrator ist min. seit Vista deaktiviert. Allerdings gibt es Menschen und Programmierer denen nicht klar ist, dass Administrator nur ein Name ist es aber keine gute Idee ist, den zu reaktivieren, weil der Name hart in der uralten Software fest kodiert wurde…
Vermutlich war MS der Meinung, weil ja der Account disabelt ist, dass das Passwort unkritisch ist…
Die Alternative wäre halt, dass das Passwort beim Setup abgefragt Würde, was dann nicht mehr unattended ist…
In der Regel nutzt man in der Antwortdatei auch nicht den "Administrator" Account, sondern einen temporären Account wie "TempAdmin", "Deployadmin" etc.
Diese Accounts löscht man dann nach dem Domainjoin, so das selbst wenn die Antwortdatei mal in falsche Hände fällt, der Angreifer da nur ein lokalen Account drin stehen hat der im fertigen System gar nicht mehr existiert.
Gruß
Es gibt 2 unattend.xml. In der einen wurde das Passwort gelöscht.
In der unattend-original.xml steht ein Passwort.
Damit kann man aber dank LAPS nichts damit anfangen, weil der Rechner sobald er joint ein neues LAPS Passwort bekommt.
Kann natürlich in bestimmten Umgebungen durchaus ein Problem darstellen!
Danke für den Hinweis. Aufräumjob ist angepasst.
Dank LAPS ist das Passwort nach dem Domainjoin eh hinfällig.
Der Generator unter https://schneegans.de/windows/unattend-generator/ löscht nun standardmäßig die Dateien C:\Windows\Panther\unattend.xml und C:\Windows\Panther\unattend-original.xml ganz zum Ende der Windows-Installation, wenn sich ein Administrator zum ersten Mal anmeldet. Details ggf. unter https://github.com/cschneegans/unattend-generator/issues/293 nachlesen.
Vielen Dank an den anonymen Blog-Leser für die Sensibilisierung!
Christoph, danke für deine Ergänzung