Windows-Sicherheit: Tester für ein Batch-Script gesucht

Ich brauche mal die Mithilfe der Blog-Leserschaft zum Thema Windows-Sicherheit. Sicherheitsexperte Stefan Kanthak hat mir ein Batch-Script zukommen lassen, mit dem die Benutzerrechte für Schreibzugriffe unter Windows getestet werden sollen. Wäre interessant, welche Ergebnisse da zusammen kommen.


Anzeige

Es geht darum, ein Skript (Batchdatei) mit (Standard-) Benutzerrechten unter Windows auszuführen. Das Script versucht die für nicht privilegierten Benutzer beschreibbaren Verzeichnisse unter:

C:\Windows\
C:\Program Files\
C:\Program Files (x86)\

herauszufinden. Dazu sollte folgender Quellcode per Zwischenablage in den Windows-Editor Notepad kopiert und dann in die Datei DUMMY.CMD gespeichert werden.

REM --- DUMMY.CMD ---
REM Copyright (C) 2021, Stefan Kanthak 
REM Download: https://skanthak.homepage.t-online.de/download/SAFER.CMD

ECHO EXIT /B 1>"%~dpn0.tmp"
MOVE "%~dpn0.tmp" "%SystemRoot%\Temp"
IF ERRORLEVEL 1 EXIT /B

COPY NUL: "%~dpn0.log"
IF ERRORLEVEL 1 EXIT /B

DIR "%SystemRoot%" /A:D /B /S 1>"%~dpn0.tmp"
DIR "%ProgramFiles%" /A:D /B /S 1>>"%~dpn0.tmp"
IF DEFINED ProgramFiles(x86) IF NOT "%ProgramFiles(x86)%" == "%ProgramFiles%" DIR "%ProgramFiles(x86)%" /A:D /B /S 1>>"%~dpn0.tmp"
FOR /F "Delims= UseBackQ" %%? IN ("%~dpn0.tmp") DO @CALL :DUMMY "%%~?"
ERASE "%~dpn0.tmp" "%SystemRoot%\Temp\%~n0.tmp"
SET /P =Bitte alle Ausgaben kopieren und mir zusammen mit der Datei "%~dpn0.log" zusenden!
EXIT /B

:DUMMY
@MKLINK /H "%~1\%~n0.bat" "%SystemRoot%\Temp\%~n0.tmp" 2>NUL:
@IF ERRORLEVEL 1 GOTO :EOF

CALL "%~1\%~n0.bat"
IF NOT ERRORLEVEL 1 ECHO %~1 1>>"%~dpn0.log"
ERASE "%~1\%~n0.bat"
REM --- EOF ---

Das Batch-Skript DUMMY.CMD versucht, das (funktionslose) Batch-Skript BATCH.BAT in jedes Unterverzeichnis von C:\Windows\, C:\Program Files\ sowie C:\Program Files (x86)\ zu kopieren und bei Erfolg auszuführen. Ist das Script dabei erfolgreich, dann schreibt es den Pfadnamen des Verzeichnisses nach DUMMY.LOG.


Anzeige

Anmerkung: in einigen dieser Verzeichnissen dürfen Benutzer schreiben und ausführen, aber nicht löschen. Daher bleiben einige (harmlose) DUMMY.BAT-Dateien zurück. Ein Benutzer mit Administratorrechten kann und sollte diese Dateien dann wieder löschen.

Die folgende Kommandozeile ist in einer mit Administratorrechten gestarteten Eingabeaufforderung einzugeben und  gibt die Pfadnamen dieser Überbleibsel aus:

FSUTIL.exe HARDLINK LIST "%SystemRoot%\Temp\DUMMY.BAT"

Das Script lässt sich auch auf dieser Webseite von Kanthak abrufen. Könnt ihr die log-Datei an Stefan Kanthak mailen – E-Mail-Adresse: stefan.kanthak (at) nexgo.de (steht oben im Script). Danke für die Unterstützung.


Anzeige

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

23 Antworten zu Windows-Sicherheit: Tester für ein Batch-Script gesucht

  1. micha45 sagt:

    Ich bin mir nicht ganz sicher, ob ich es richtig verstehe:

    Mal ganz ab von der Sinnhaftigkeit einer solchen Aktion, die sich mir nicht so richtig erschließen will, soll man also einem völlig Fremden Einblick in das eigene System geben und durch Versenden der Logs per E-Mail auch noch die eigene E-Mailadresse preisgeben?

    Braucht man für eine solche Prüfung wirklich andere? Das kann man doch sehr leicht selbst testen.
    Wenn nichts an den Grundeinstellungen verändert wurde, sind die Bedingungen doch bei jedem gleich.

    Kann natürlich sein, dass ich die Intention dahinter nicht verstehe.
    Aber wie auch immer, so etwas kommt für mich nicht in Frage.

    • Dat Bundesferkel sagt:

      "Braucht man für eine solche Prüfung wirklich andere?"
      Nein. Überhaupt nicht. Nicht hierfür. Muß jeder für sich selbst entscheiden, wie freizügig er mit der Preisgabe seiner Daten ist. Man sollte sich aber dessen bewußt sein, daß spätestens beim Versand der E-Mail (im schlimmsten Fall von einem Desktop-Client heraus) sehr, sehr viele sensible Daten stehen, die ein System unter Umständen von außen angreifbar machen (bspw. bei einem eigenen Mailserver).

    • Martin Feuerstein sagt:

      Kleiner Logikfehler, wenn man SAFER so wie von Stefan Kanthak beschrieben anwenden würde:
      – Das Skript soll von einem Benutzer OHNE erhöhte Rechte ausgeführt werden
      – Das Skript muss an einer Stelle gespeichert werden, wo Benutzer diese ausführen können
      – die Logdatei wird ins gleiche Verzeichnis geschrieben, wo auch die eben ausgeführte Skriptdatei liegt.

    • 1ST1 sagt:

      Der Sinn des ganzen sind die beiden Windows-Funktionen "Software-Restriction-Policy" (SRP), wird oft wegen dem Registry-Pfad auch als "SAFER" bezeichnet, und "Applocker".

      Dabei geht es darum, die Ausführung von Programmen zu sperren, die in Benutzer-beschreibbaren Pfaden liegen. Diese beiden Funktionen geben (über vordefinierte Regeln) pauschal die Pfade c:\program files, c:\program files (x86) und c:\windows für alle Benutzer frei. Würde es diese Regeln nicht geben, könnte sich ein Benutzer nicht mal mehr anmelden können, sobald SRP oder Applocker aktiv sind! Aber wie der Text und der Batch von S.Kanthak schon angedeutet, gibt es unter diesen Pfaden auch Unterverzeichnisse, in die Benutzer reinschreiben können. Das können sich dann auch Schadprogramme zu Nutze machen, obwohl SRP oder Applocker eigentlich genau das verhindern sollen, sprich SRP/Applocker werden ausgetrickst!

      Der Sinn dieses Scriptes ist dann, diese Standardregeln besser zu granulieren, das heißt, dieses Batch-Script liefert dann Ordnerpfade, die über weitere Regeln gesperrt werden.

      Ich verstehe allerdings nicht, warum Stefan Kanthak hier das Rad zum Dritten Mal neu erfinden muss, denn solche Scripte gibt es bereits zwei Mal, und dort auch die ganzen Grundlagen zu SRP und Applocker.

      https://schneegans.de/windows/safer/ (SRP/SAFER)
      https://www.gruppenrichtlinien.de/artikel/applocker-oder-software-restriction-policies-loecher-im-sicherheitszaun

      Zusätzliche Hinweise aus eigener Erfahrung, ich habe SRP und Applocker schon mit Hilfe der Registry, lokaler Richtlinien als auch AD-Gruppenrichtlinen in Kundenumgebungen umgesetzt, von den PCs meiner eigenen Kinder und Eltern als auch in Firmenumgebungen mit mehreren 1000 Usern auf Clients und Servern, das heißt, ich habe da schon ein bischen Erfahrung… (und mir Anfangs auch die Finger verbrannt!)

      Daher Tipps vorneweg: Wenn man diese Funktionen nicht mit Hilfe von AD-Gruppenrichtlinien administrieren will/kann, macht es bloß nicht mit lokalen Richtlinien. Entweder per GPO oder Registry, und letzteres nach Methode "b" die ich unten skizziere! Mit lokalen Richtlinien kommt man schnellstens in des Teufels Küche, wenn man die Regeln nicht in der richtigen Reihenfolge definiert. Mal drüber nachdenken, vielleicht kommt ihr darauf, warum ich das empfehle… Auch doof ist das gemischte Arbeiten mit lokalen Richtlinien und Registry, am Besten beide Vorgehensweisen nicht mischen!!! Und bei AD-GPOs sollte man es erstmal an einem Test-PC ausprobieren, bevor man alle Benutzer und sich selbst z.B. wegen einer vergessenen "c:\windows\* erlauben-Regel" komplett aussperrt – dann kann sogar winlogon.exe nicht mehr gestartet werden!

      Was man nirgends ließt, ist dass man bei SRP und Applocker darüber hinaus noch mehr aufpassen muss! Zum einen werden standardmäßig nur Regeln für die schon genannten Standard-Ordner definiert. Wenn man das macht, ist man recht schnell aufgeschmissen, denn nichtmal Microsoft selbst hält sich dran, dass ausführbare Dateien nur in diese Pfade gehören. Diverse Programme und Tools, und das nicht nur von Microsoft, legen aber auch ausführbare Programme und Scripte in C:\ProgramData (Sophos Antivirus, Google Chrome, …) und im Benutzerprofil ab (OneDrive, Teams, …) und wenn man die nicht freigibt, funktioniert es nicht. Hier hilft nur als ein "dir C:\ProgramData\*.exe /s" bzw. C:\Users\*.exe /s" (exe auch durch bat, cmd, ps1 ersetzen!), um die zu finden, und per Extra-Freigabe zu genehmigen. Aber keine Angst, man kann da bei von mehreren Benutzern benutzten PCs durchaus mit Wildcards in den Freigaberegeln arbeiten, z.B. um "C:\Users\*\AppData\Local\Microsoft\Teams" frei zu geben. Wer Applocker nutzen kann (Enterprise-Lizenz) löst das aber noch eleganter als mit Pfadregeln, in dem man diese Sachen per Signatur (Hersteller Microsoft, Programmname Teams, alle Versionen – oder noch allgemeiner: Alles vom Hersteller Microsoft) per GPO freigibt, bei signierten EXE-Dateien und PS1-Scripten ist das die elegantere Version. Per Signatur freigegebene Dateien können quasi überall liegen!

      Die hohe Kunst sind dann wie schon angedeutet, die Ausnahmen, die mit den Scripten speziell unter c:\windows, aber auch unter den anderen Pfaden gefunden und gesperrt werden müssen, sonst war alles für die Katz!

      Und noch ein ganz heißer Tipp zur SRP-Umsetzung per Reg-Dateien wie es bei schneegans.de beschrieben ist. Bloß nicht die dort einzeln gezeigten Reg-Dateien einzeln in die eigene Registry importieren, denn sofort wenn der safer-Pfad in der Registry existiert, ist das Ding schwarf, und wenn man dann noch keine Regel mit c:\windows erlauben in der Registry hat, hat man wirklich gelitten!

      Um diese Klippe zu umfahren, gibt es zwei Lösungen:
      a) Erstmal alle Einzel-Regs per Texteditor zusammen fügen, und bloß keine Wichtige vergessen!!! Insbesondere nicht die für die genannten Standard-Ordner inklusive c:\ProgramData, sonst sperrt man sich von dem PC für alle weitere Aktionen aus!
      b) In ALLEN Einzel-Regs den SAFER-Pfad erstmal umbenennen: Aus "HKLM:\SOFTWARE\Policies\Microsoft\Windows\safer" erstmal "HKLM:\SOFTWARE\Policies\Microsoft\Windows\saferx" machen, dann kann man schonmal die Einzel-Regs in der Registry sammeln, und wenn man dann der Meinung ist, man hat alle Regeln drin, den Regedit starten, sich den Pfad entlang hangeln und dann "saferx" in "safer" umbenenennen. Erst dann ist SRP (sofort!) freigeschaltet. Beim ersten Mal bloß nicht den Regedit schließen, erstmal was aus dem Windows-Ordner starten! Man kann SRP durch nochmaliges Umbenennen auch wieder ausschalten.

      Natürlich darf am Ende der Hinweis auf S.Kantahks Webseite zu dem Thema nicht fehlen: https://skanthak.homepage.t-online.de/SAFER.html Der Artikel, scheinbar inzwischen nochmal überarbeitet seit dem ich mich damals durchgerackert habe, ist super, aber auch superlang und superschwer zu verstehen, weil der Autor wirklich in jedes Detail eingeht, auch wenn nicht jedes Detail für eine Erst-Implementierung noch nicht benötigt wird. Ich habe daher damals meine ersten Gehversuche mit schneegans.de gemacht, das war einfacher zu verstehen. Erst mit den Erfahrungen konnte ich auch die Anleitung von S.Kanthak nachvollziehen und nutzen.

      • Dummerweise geht's NICHT um SAFER alias SRP bzw. AppLocker, sondern um Schwachstellen zweier Windows-Komponenten, die jedoch mit SRP sowie AppLocker und den ohnehin notwendigen Verbotsregeln entschärft werden.

        Apropos Erfindung des Rads: das Batch-Skript ist "minimal art", es missbraucht mit allergrößter Absicht keinen aufgeblasenen und trivial angreifbaren Schrott wie Posershell und .NET Framework, es vermeidet die Fehler anderer in Posershell gefrickelter (hybrider) Skripts, ist älter als diese, setzt keine Installation von nicht mit Windows gelieferter Komponenten wie .NET Core voraus und funktioniert alleine mit den Bordwerkzeugen von Vista oder neueren eNTen (auch unter Windows PE/RE).

        • Maximilian sagt:

          Findest du, dass deine Glaubwürdigkeit erhöht wird, wenn du Powershell mit deinem Phantasienamen beschreibst? In infantiler Weise noch dazu?

          Das sagt mehr über dich aus als du möchtest, das versichere ich dir.

  2. HessischerBub sagt:

    Der eigentliche Test ist: Kann ich Leute motivieren etwas zu tun das sie nicht verstehen.

    "Es ist nicht leicht, ein Gott zu sein."

    Da ging es auch darum jemand anders zu testen als dieser dachte.

    • Ärgere das Böse! sagt:

      Das habe ich mir auch überlegt.

      Und deswegen den Test auf einem Testrechner mitgemacht. Denn ich habe von beiden die Adresse :-)
      Die Webseiten sind für die Polizei und Staatsanwaltschaften auch einsehbar.

      In irgendeinem schrägen Blog hätte ich sicher nicht mitgemacht.

      Bin ich auf den Test reingefallen, oder sind die anderen beiden auf mich reingefallen?

      • Günter Born sagt:

        Leute, hängt das Thema nicht so hoch. Das Batch-Script ist im Quellcode verfügbar – die erstellte Log-Datei lässt sich im Editor ansehen. Wenn es nicht Zig-Millionen Ordner sind, postet den Log meinetwegen hier als Kommentar. Stefan kann dann die Infos hier abrufen (falls wer Probleme mit "da bekommt jemand meine E-Mail-Adresse mit" hat).

        Es geht darum zu sehen, welche Ordner in den genannten Pfaden unter diversen Windows-Builds Schreib- und Ausführungsrechte für Standardnutzer haben. Normalerweise sollte kein Schreibrecht auf diese Ordner vorhanden sein.

        Und da wir verschiedene Windows-Versionen und Builds vorliegen haben, ist ein Test von mehr als 2 Leuten hilfreich.

        • Ärgere das Böse! sagt:

          Ich hänge das Thema überhaupt nicht hoch.

          Ich habe Stefan das Log-File heute morgen um 10:35 gemailt.

          Bei mir sieht es so aus:
          C:\WINDOWS\Tasks
          C:\WINDOWS\Temp
          C:\WINDOWS\tracing
          C:\WINDOWS\Registration\CRMLog
          C:\WINDOWS\System32\FxsTmp
          C:\WINDOWS\System32\Tasks
          C:\WINDOWS\System32\Tasks_Migrated
          C:\WINDOWS\System32\Com\dmp
          C:\WINDOWS\System32\Microsoft\Crypto\RSA\MachineKeys
          C:\WINDOWS\System32\spool\PRINTERS
          C:\WINDOWS\System32\spool\SERVERS
          C:\WINDOWS\System32\spool\drivers\color
          C:\WINDOWS\SysWOW64\FxsTmp
          C:\WINDOWS\SysWOW64\Tasks
          C:\WINDOWS\SysWOW64\Com\dmp

          Edition Windows 10 Pro Insider Preview
          Version Dev
          Installiert am ‎24.‎03.‎2021
          Betriebssystembuild 21343.1000
          Leistung Windows 10 Feature Experience Pack 321.7401.0.3

  3. bon-go sagt:

    Der Trick mit dem Umleiten in eine Datei unterhalb %SystemRoot%\Temp und anschließendem verlinken war mir noch gar nicht bekannt. Man lernt nie aus. Auch was dabei rauskommt. Nettes Feature wenn man an den Ordner Tasks denkt. Interessant auch wegen %programdata% und den div. MS Ordnern darunter, gleich probieren.

    Auf einem seit 7 Jahren laufendem Windows 8.1 x64:
    C:\Windows\Tasks
    C:\Windows\Temp
    C:\Windows\tracing
    C:\Windows\debug\WIA
    C:\Windows\PCHEALTH\ERRORREP\QHEADLES
    C:\Windows\PCHEALTH\ERRORREP\QSIGNOFF
    C:\Windows\PLA\Reports
    C:\Windows\PLA\Rules
    C:\Windows\PLA\Templates
    C:\Windows\PLA\Reports\de-DE
    C:\Windows\PLA\Reports\ru-RU
    C:\Windows\PLA\Rules\de-DE
    C:\Windows\PLA\Rules\ru-RU
    C:\Windows\registration\CRMLog
    C:\Windows\System32\FxsTmp
    C:\Windows\System32\Tasks
    C:\Windows\System32\Com\dmp
    C:\Windows\System32\LogFiles\WMI
    C:\Windows\System32\Microsoft\Crypto\RSA\MachineKeys
    C:\Windows\System32\spool\PRINTERS
    C:\Windows\System32\spool\SERVERS
    C:\Windows\System32\spool\drivers\color
    C:\Windows\SysWOW64\FxsTmp
    C:\Windows\SysWOW64\Tasks
    C:\Windows\SysWOW64\Com\dmp
    C:\Program Files\Git\dev
    C:\Program Files\Git\dev\mqueue
    C:\Program Files\Git\dev\shm
    C:\Program Files\Kyocera\NetViewer\KNV\conf
    C:\Program Files\Kyocera\NetViewer\KNV\log
    C:\Program Files\Kyocera\NetViewer\KNV\conf\flags
    C:\Program Files\Lenovo\Lenovo Solution Center\QualityStats
    C:\Program Files\Microchip\xc8\v2.31\etc
    C:\Program Files\Microsoft SQL Server\110\Shared\ErrorDumps
    C:\Program Files\Microsoft SQL Server\130\Shared\ErrorDumps
    C:\Program Files (x86)\No23 Recorder
    nahezu alle Ordner unterhalb C:\Program Files (x86)\Adobe!
    nahezu alle Ordner unterhalb C:\Program Files (x86)\Arduino\hardware\Arduino_STM32 – toll
    C:\Program Files (x86)\Common Files\Adobe\StartupScripts
    C:\Program Files (x86)\Common Files\Adobe\Color\Profiles
    C:\Program Files (x86)\Common Files\Adobe\Color\Settings
    nahezu alle Ordner unterhalb C:\Program Files (x86)\Microsoft Visual FoxPro 9 – ein Oldie halt

    Es gibt noch einige weitere Verzeichnisse die ich hier rausgenommen habe. Ist tlw. selbstgewählt bzw. so richtig alte Software.

    Reste bleiben unter:
    \Windows\Temp\dummy.tmp
    \Windows\Temp\dummy.bat
    \Windows\System32\Tasks\dummy.bat
    \Windows\System32\Com\dmp\dummy.bat
    \Windows\System32\spool\PRINTERS\dummy.bat
    \Windows\System32\spool\SERVERS\dummy.bat
    \Windows\SysWOW64\Tasks\dummy.bat
    \Windows\SysWOW64\Com\dmp\dummy.bat

    • AUTSCH: das sieht ja RICHTIG übel aus!
      | C:\Program Files\Git\dev

      | C:\Program Files\Kyocera\NetViewer\KNV\…

      Und das besonders einladend:
      | C:\Program Files (x86)\Common Files\Adobe\StartupScripts

      Apropos Reste: in einigen Verzeichnissen dürfen Standard-Benutzer zwar schreiben und neue Dateien anlegen, diese aber nicht löschen. Siehe die Ausgabe von ICACLS.exe "Pfadname" für die oben genannten Verzeichnisse.

      • Zusatzfrage/aufgabe: steht ein für unprivilegierte Benutzer schreibbares Verzeichnis im Suchpfad des Systems?
        Der folgende Einzeiler zeigt diese an:
        FOR %? IN ("%PATH:;=" "%") DO @(COPY /Y NUL: "%~?\.cmd" 1>NUL: 2>NUL: && ((CALL "%~?\.cmd" && ECHO %?) & ERASE "%~?\.cmd"))

        Falls ja, dann ist jeder unprivilegierte Benutzer über kurz oder lang Administrator…

  4. Dat Bundesferkel sagt:

    "Sicherheitsexperte" + "(at) nexgo.de" + "unsinniges Skript*" = NÖ!

    Davon abgesehen störe ich mich an seiner äußerst herablassenden Art in Kommentaren (ohne, daß er selber etwas Besonderes geleistet hätte – wenn es der "Sicherheitsexperte" ist, der auch bei VW Wolfsburg als System Analyst arbeitet, wundert mich bei deren Softwareanwendungen gar nichts mehr).

    Ein Experte hostet auch nicht auf t-online und sammelt wild CVEs aus dem WehWehWeh zusammen (man verweist direkt auf die Quellen) und läßt sich E-Mails an nexgo.de schicken. Siehe:
    htt**://mxtoolbox.com/emailhealth/nexgo.de/
    htt**://tls.imirhil.fr/smtp/nexgo.de

    Einfach nur "nö". "Nö." Und nochmals "nö!".

    *Das Skript liefert im besten Fall widersprüchliche Ergebnisse, insbesondere dann wenn Anwendungen, die installiert wurden (mittels UAC mit Admin-Rechten) dann in den jeweiligen Ordnern die Rechte ausgeweitet haben (ja, derlei Anwendungen existieren).
    Es sagt demnach rein gar nichts aus. Das einzig aussagekräftige Datensammelsurium kann er selbst erlangen, in dem er sich diverse Builds virtualisiert und ohne Fremdkontamination sein Skript durchlaufen ließe.

    • Martin Feuerstein sagt:

      nexgo.de (einfach mal eingeben) endet bei Arcor (ehemaliger deutscher Provider), T-Online ist (immer noch) ein großer deutscher Provider, vielleicht ist das Hosting dort anonym, vielleicht nicht, wird schon seine Gründe haben, dort ein paar KB mit einer beinahe javascriptfreien Homepage abzulegen.

      Die Informationen zu SAFER sind schon recht fundiert, das im Beitrag genannte Batch-Skript tut genau was es soll (kann jeder nachprüfen), ist dabei klein und effizient – Verzeichnisse finden, in denen der Benutzer Schreib- und Ausführungsrechte hat. Die Einblicke sind… interessant. Auf meinem Heim-PC siehts demnach auch aus wie Dresden '45 (schlimmer als bon-gos PC, sh. oben), aber es wäre interessant wo es noch schlimmer ausfällt.

      Die Ausdrucksweise von Stefan Kanthak ist häufig etwas rau, aber in der Regel zutreffend. Wir (oder wenigstens ich) sind hier aber auch wegen der Informationen, nicht vordergründig wegen dem meist guten Ton.

      • Dummschwätzer und Kleinkinder, die nicht einmal ihren eigenen Namen schreiben können, solltest Du ignorieren!

        Falls Du "Dresden" aus anderer Perspektive sehen möchtest, dann führe folgenden Kommandozeilenblock in dem bei der Installation angelegten Benutzerkonto (egal ob das noch vernarrenkappt oder schon herabgestuft ist) in einer UNPRIVILEGIERTEN Eingabeaufforderung aus:

        2>NUL: (
        ICACLS.exe "%ProgramData%\*" /FindSID "%USERNAME%" /C /T
        ICACLS.exe "%ProgramFiles%\*" /FindSID "%USERNAME%" /C /T
        ICACLS.exe "%ProgramFiles(x86)%\*" /FindSID "%USERNAME%" /C /T
        ICACLS.exe "%SystemRoot%\*" /FindSID "%USERNAME%" /C /T
        ) | FINDSTR.exe /B /C:"SID "

        Idealerweise sollten KEINE Treffer angezeigt werden.
        Falls doch, dann sieh Dir die ACLs der Treffer genau an.

        PS: das völlig abgebrannte Pommerland erkundest Du unter https://skanthak.homepage.t-online.de/sloppy.html

  5. Günter Born sagt:

    Danke für die Handvoll Teilnehmer, das Projekt ist imho abgeschlossen. Gab einige Erkenntnisse – die Historie beeinflusst, welche Ordner mit Standardbenutzerrechten beschreibbar sind.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

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.

Du findest den Blog gut, hast aber Werbung geblockt? Du kannst diesen Blog auch durch eine Spende unterstützen.