Mit AppLocker lässt sich auf Windows-Systemen steuern, welche Anwendungen ausgeführt werden dürfen. Stefan Kanthak hatte mir bereits Anfang Dezember 2025 in einer kurzen Mail mitgeteilt, wie man AppLocker-Richtlinien unter Microsoft Windows quasi mit einem Mausklick installieren kann. Er hat dazu ein kurzes Script mitgeschickt, und ich stelle die Information heute mal im Blog ein.
Hintergrund AppLocker
AppLocker wurde bereits mit Windows 7 eingeführt und ermöglicht Administratoren vorzugeben, welche Anwendungen auf Windows-Clients ausgeführt werden dürfen. Das soll verhindern, dass Endbenutzer nicht genehmigte Software auf ihren Computern ausführen.
AppLocker-Richtlinien können für alle Benutzer eines Computers oder für einzelne Benutzer und Gruppen gelten. AppLocker-Regeln können basierend auf Folgendem definiert werden:
- Attribute des Codesigningzertifikats, das zum Signieren einer App und ihrer Binärdateien verwendet wird.
- Attribute der Binärdateien der App, die aus den signierten Metadaten für die Dateien stammen, z. B. Originaldateiname und -version oder der Hash der Datei.
- Der Pfad, in dem die App oder Datei auf dem Datenträger vorhanden ist.
AppLocker wird gemäß dieser Microsoft-Webseite von aktuellen Versionen von Windows 10 und Windows 11 (und natürlich auch Windows Server) unterstützt. Die Wikipedia hält eine Übersicht zur Applocker-Unterstützung diverser Windows-Versionen bereit – etwas genauer geht dieser Blog-Beitrag auf das Thema ein. Applocker-Richtlinien werden ab Windows 10 2004 ohne weitere Restriktionen unterstützt. In diesem Support-Dokument gibt Microsoft Hinweise, wann man AppLocker oder das empfohlene App Control verwenden sollte.
AppLocker-Richtlinien mit einem Klick aktivieren
Stefan Kanthak hat mir Anfang Dezember 2025 das nachfolgende Script geschickt, mit dem man AppLocker-Richtlinien auf aktuellen Windows-Systemen mittels Mausklick aktivieren kann. Falls also jemand (private) Windows-Systeme mit AppLocker besser absichern möchte, lassen sich die folgende Anweisungen in eine Textdatei *.wsf (Windows Scripting Host File) einfügen und speichern.
Dabei ist vor dem Speichern das zwischen "<![CDATA[" und "]]>" stehende XML-Schnipsel "AppLockerPolicy Version='1' />" durch die zu installierende AppLocker-Richtlinie zu ersetzen. Das Script ist dann mit administrativen Berechtigungen auszuführen und Windows im Anschluss neu zu starten.
<?xml version='1.0' encoding='US-ASCII' standalone='yes' ?>
<job>
<object id='AppIdPolicyHandler' classid='clsid:F1ED7D4C-F863-4DE6-A1CA-7253EFDEE1F3' />
<script language='JScript'>
AppIdPolicyHandler.SetPolicy('', getResource('Policy'))
</script>
<runtime>
<description>Set AppLocker Policy on Windows 7 and later versions</description>
</runtime>
<resource id='Policy'><![CDATA[<AppLockerPolicy Version='1' />]]></resource>
</job>
Kanthak hat diese Webseite zum Script samt Hinweisen veröffentlicht (die "Defender-Warnung" der Seite kommt, weil das Eicar-Test-Virus in einem Datenpaket zum Testen der Browser-Reaktion eingebunden ist). Ein digital signiertes fertiges Script gibt es hier als .wsf-Datei.
Auf administrator.de hat DerWoWusste bereits 2021 in diesem Beitrag skizziert, wie man AppLocker mit den Windows Home-Editionen einsetzt. Der Post hier aus 2015 geht auf die Konfigurierung von AppLocker-Richtlinien ein. Auch dieser ältere Beitrag enthält einige Hinweise zur Konfigurierung der Richtlinien. Vielleicht hilft es jemanden, ein privates Windows-System abzusichern. Aber immer darauf achten, sich nicht selbst als Administrator auszusperren.
Stefan Kanthak hat auf seiner Webseite die beiden Artikel hier und hier mit Hinweisen zu diversen Einstell- und Konfigurier- und Blockiermöglichkeiten von Windows-Systemen veröffentlicht.
MVP: 2013 – 2016
Über diesen Eicar-Blödsinn auf Kanthaks Webseite kann ich nur den Kopf schütteln. Er verhindert dadurch, dass Leser, die hinter irgendwelchen Proxies mit Deep-Packet-Inspection und ähnlichen Schutzmaßnahmen sitzen, auf die Seite zugreifen können. Offensichtlich will er verhindern, das professionelle Admins seine Veröffentlichungen lesen können.
Im übrien empfehle ich nicht, das Sript vom Kantak einfach so 1:1 zu übernehmen, und zwar aus mehreren Gründen:
– AppLockerPolicy Version='1' müsste nach einem Verständnis lediglich die deprecated Software-Restriction-Policy (SRP/Safer, Applocker V2 wird eigentlich erst ab Enterprise-Lizenz unterstützt) sein, aber hier bin ich mir nicht sicher. In anderen Anleitungen findet sich auch der Wert "1", wenn es hier also tatsächlich um Applocker geht, braucht der Wert nicht angepasst zu werden.
– Das Script legt offensichtlich keinerlei Regeln für %program files% an. Ob Applocker diese Regeln automatisch anlegt, wenn man auf diese Weise Applocker aktiviert, ist mir unbekannt. Immerhin wird eine Regel mit Ausnahmen für %windir" in dem wsf-Script angelegt. Diese Regeln sind aber absolut notwendig, sonst kann ein Benutzer keinerlei installierte Programme starten, und das fängt – wenn %windir% fehlt – schon bei winlogon.exe an, welches nach der Anmeldung gestartet wird. Der Applocker-aktivierte Benutzer könnte sich nicht mal mehr anmelden.
– Die Freigabe von pauschal %Windir% alleine ist unsicher, denn in der Verzeichnisstruktur finden sich dutzende Unterordner, welche für Benutzer zum Schreiben berechtigt sind. Es gelingt somit, aus Unterverzeichnissen von %windir% beliebige Programme zu starten, wenn man dafür keine Ausnahmen erstellt. Das Script legt diverse bekannte Ausnahmen an, aber ob das – je nach installierter Windows-Edition – vollständig ist, mag ich anzweifeln. Es gibt diverse Tools und Scripte, um diese Ordner zu finden, um sie in die Freigabe %windir" als Ausnahme aufzunehmen. Sogar Kanthak selbst hat mal so ein Script (für Software-Restriction-Policy, ich finde es gerade nicht, es war aber auch hier im Blog mal ein Thema.) veröffentlicht, um diese Verzeichnisse zu finden. Auch bei schneegans.de wird man fündig ( https://schneegans.de/windows/safer/#anpassen -> "Für Benutzer schreibbare Verzeichnisse finden" ), außerdem gibt es in der Sysinternal-Suite "AccessEnum" ( https://learn.microsoft.com/en-us/sysinternals/downloads/accessenum ) und es gibt Cyberark "Evasor" ( https://github.com/cyberark/Evasor ), mit denen man solche Verzeichnisse finden kann. Und viele mehr, auch Anleitungen wie Sand am Meer, wie man mit diesen Ausnahmen umgeht. Also unbedingt das Ergebnis eigener Versuche mit den Exceptions in dem Script abgleichen und ggf. ergänzen!
– Für Domain-Admins wichtig: Die Standardregeln für Applocker beinhalten KEINE Freigaben für SYSVOL einer Domäne, Jahre lange benutzte per GPO verteilte Login/Logoff-Scripte werden nicht mehr ausgeführt, das muss man zwingend als Zusatzregel berücksichtigen. Hier darf ausnahmsweise auch eine Pfad-Regel verwendet werden, denn normale User haben auf SYSVOL keine Schreibrechte, da kann höchstens ein Domain-Admin seinen Schabernak treiben.
– Manche Programme legen bei Progamm-Installation oder bei Updates auch Exe-Dateien in c:\programdata ab. Ich glaube Google-Chrome ist/war so ein Kandidat, hier muss man – mehr oder weniger nach Trial&Error zusätzliche Regeln finden, die man als Signatur-Regeln anlegen sollte.
– Bei Microsoft das sind Idioten, Teams.exe und Onedrive.exe liegen in %userprofile_appdata und werden mit den Standardregeln gesperrt. Wer das so haben will, dann ists gut, wenn nicht, braucht man Signaturregeln. (Auf KEINEN Fall Pfadregeln für sowas nehmen!)
– Powershell versucht beim Start ein PS1 Script mit teilweise zufälligem Dateinamen aus einem Unterverzeichnis des Benutzerprofils zu starten. Gelingt dies nicht, weil Applocker das sperrt, wechselt PS in den Constrained Language Mode mit eingeschränktem Befehlsumfang. Schaltet man den entsprechenden Ordner als Pathregel frei, öffnet man eine Tür für das Ausführen beliebiger Powershellscripte aus dem Verzeichnis, sie müssen nur im Dateinamen den festen Namensbestandteil haben, den Powershell auch verwendet.
– Das Kanthaksche Script verwendet wscript.exe. Das ist ein Windows-Bordmittel das gerne für Living Off the Land Angriffe genutzt wird und es ist "deprecated". Sollte man genau wie cscript per Applocker sperren. Es gibt noch jede Mege weitere beliebte LOtL-Tools in %system32%, die man für normale Benutzer sperren sollte, curl fällt darunter, aber auch das kaum beachtete schtask (schtask.exe slash-run "beliebige.exe" umgeht Applocker!!!, siehe https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/schtasks ). Außerdem sollte man deny-Pfad-Regeln für Wildscards wie "*.jpg.exe", "*.docx.exe" usw. anlegen, seit kreativ.
– Die Anleitung bei administrator.de erstellt KEINE Regeln für Exe-Dateien in %windir%, %programfiles%. Solange ihr privat an einem PC mit lokalen Adminrechten arbeitet, klappt das, aber bei jemandem der lokaler Admin ist, macht Applocker insgesamt keinen Sinn. Aber wehe, wenn ihr für normales Arbeiten am PC getrennte Adminkonten habt. Hier müssen für Programme und Scripte und Installer unbedingt die Standardregeln erstellt werden, so wie es für "Apps" dort gezeigt wird. Der PC-Welt-Artikel zeigt es richtig.
– Wer hier mit gpedit und secpol auf einem lokalen PC seine Experimente macht, und die Standardfreigaben oder etwas vergleichbares vergisst und sich aussperrt, darf Windows neu installieren, man kommt da nicht mehr raus, wenn man sich nicht mehr anmelden kann! Nicht vergessen, erst Winlogon verschafft einem lokalen Admin nach der Anmeldung seine Rechte, das ist ein klassisches Henne-Ei-Problem. Admins, die das per AD-Gruppenrichtlinien machen, sind fein raus, sofern sie erste Experimente mit einem einzelnen PC machen, denn an den AD-Gruppenrichtlinieneditor kommt man über einen anderen PC oder Server noch dran und kann die Misere bereinigen.
– Pfadregeln so gut es geht vermeiden. Die machen eigentlich nur als Deny-Regeln Sinn, um einzelne Exe-Dateien oder Scripte in grundsätzlich freigegebenen Pfaden wie %windir% zu sperren. Allow-Regeln insbesondere in User-beschreibbare Ordner auf keinen Fall erstellen!
– Immer dran denken, ein Angreifer kann die SRP- und Applocker-Regeln per Regedit auslesen und wird die Schwachstellen des aktiven Regelwerks finden.
Für Firmenadmins findet sich hier übrigens ein guter Guide, wie man das Thema in den Gruppenrichtlinen direkt angeht, aber lasst die Applocker-Policy nicht schon beim Anlegen auf alle PCs los, ihr setzt euch fett in die Nesseln, das verspreche ich euch. Erst mal "authenticated users" aus der Delegation der Richtlinie raus nehmen und einen einzelnen Test-PC damit verknüpfen und dann Richtlinie bauen, testen, lernen, anpassen, testen, lernen, anpassen, … und erst wenn alles auf dem Test-PC (wieder) wie erforderlich funktioniert (mehrer Useraccounts aus verschiedenen Abteilungen clonen und damit probieren!), weitere Test-PCs aus verschiedenen Abteilungen nach Absprache mit den Benutzern rein nehmen! https://www.hackingarticles.in/windows-applocker-policy-a-beginners-guide/ Bei nicht sorgfältigem Arbeiten sperrt ihr mit ein bisschen Pech alle eure Benutzer aus, weil die nichtmal mehr winlogon starten dürfen. Ihr macht euch damit bei eurem Chef und den Usern extrem unbeliebt. (Hinweis: Wer seine Computerobjekte nicht in der Standard-OU Computers liegen hat, kann sich im Notfall behelfen, in dem er einen neuen PC ins AD aufnimmt, der landet dann nämlich dort und die Applocker-Policy wirkt nicht, wenn sie nur auf die produktiven Computer-OUs verlinkt ist! Dann kann zumindestens von dem PC aus die Richtlinie erstmal wieder ausgeschaltet werden. Oder man meldet sich direkt an einem DC oder einem Server in einer anderen OU an. So hab ich mal bei einem Kunden mit ca. 10.000 User aus der Patche geholfen, nachdem ein Admin von dort so schlau war, die Applocker-Regeln mal radikal vereinfachen zu müssen und wirklich alle Leute ausgesperrt hatte und sich dann dort niemand mehr behelfen konnte.)
Wer übrigens eine ausgefeiltere XML sucht, in der %windir%, %program files% und vieles mehr schon inklusive bekannter Ausnahmen noch viel granulierter schon berücksichtigt sind, wird hier fündig: https://github.com/nsacyber/AppLocker-Guidance/blob/master/AppLocker%20Starter%20Policy/Windows10_AppLocker%20Starter%20Policy.xml Ungeprüft übernehmen und auf alle User ausrollen sollte man aber auch das nicht!
Zitat
"– AppLockerPolicy Version='1' müsste nach einem Verständnis lediglich die deprecated Software-Restriction-Policy (SRP/Safer, Applocker V2 wird eigentlich erst ab Enterprise-Lizenz unterstützt) sein, aber hier bin ich mir nicht sicher. "
—
"1" ist SRP, richtig.
"2" ist Applocker.
Applocker ist seit Windows 10 Version 1903 in allen Varianten enthalten, nicht nur Enterprise, sondern auch Home.
Eigentlich war erst erst ab Version 2004 enhalten, wurde dann aber auch für 1903 rückportiert.
Bei Windows 7 war es nur in der Ultimate-Variante enthalten.
2. Zitat:
"Das Script legt offensichtlich keinerlei Regeln für %program files% an."
—
Diese Regeln müssen in dem XML stehen, das du anstelle des markierten Textes einsetzt (AppLockerPolicy Version='1', inklusive der spitzen Klammern).
3.Zitat:
"Dutzende Unterordner, welche für Benutzer zum Schreiben berechtigt sind. Es gelingt somit, aus Unterverzeichnissen von %windir% beliebige Programme zu starten, wenn man dafür keine Ausnahmen erstellt. Das Script legt diverse bekannte Ausnahmen an"
—
"Das" Script legt diese Ausnahmen nicht an.
Jedenfalls nicht das hier im Artikel verlinkte Script und auch nicht das Primärsript bei Kanthak.
Erst das Eleven.xml Script im weiterführenden Link enthält diese Regeln für das %WinDir%.
Die Regeln für %ProgramDir% fehlen aber noch und diese sind je nach System bzw den installierten Programmen unterschiedlich.
Ich sehe schon, du kennst dich ansonsten auch aus. Und dem Kanthak seine Simpel-Anleitung ist unvollständig, Knieschuss vorraussehbar. Und das verwundert, ist das Thema Application-Control ja doch eines seiner Lieblingsthemen.
Dass Applocker inzwischen auch in Home und Pro geht, ist mir neu, aber gut zu wissen! Applocker ist besser als SRP, vor allem weil man damit auch Regeln für einzelne Benutzer und Gruppen erstellen kann. Bei SRP geht das nur pauschal für alle. Für Gruppen ist sinnvoll, weil es gelegentlich "historisch gewachsene" Software gibt, die nur aus c:\programmname funktioniert oder im Userprofil liegt, da kann man die Regeln dann fest auf diese Anwendergruppe festnageln.
Mit Win 10 1903 wäre ich aber nicht sicher. Habe im Sommer 2019 mal wo Applocker komplett bei einem Kunden eingeführt, und da funktionierte es nicht mit Pro, erst als er deswegen (endlich) auf Enterprise hochlizenziert hat, gings. Übergangsweise hatte ich dann erst vereinfacht SRP-Regeln angelegt, und dann die für Applocker kopiert und stark erweitert.
Zitat:
"Dass Applocker inzwischen auch in Home und Pro geht, ist mir neu, aber gut zu wissen!"
"Mit Win 10 1903 wäre ich aber nicht sicher."
—
Da steht's:
"AppLocker ist in allen Editionen von Windows mit Ausnahme von Windows 10 Version 1809 oder früher enthalten."
learn. microsoft. com/de-de/windows/security/application-security/application-control/app-control-for-business/applocker/applocker-overview
Applocker für Version 1903 wurde aber erst nachträglich eingeführt, nachdem es bei Version 2004 so gut angenommen wurde. Also im Sommer 2019 ging das noch nicht, aber ab Ende 2020 oder Anfang 2021 ging es dann auch auf Version 1903. Das war ein Feature-Backport.
Bei Home ist aber der Gruppenrichtlineneditor nicht vorhanden. Deswegen kann man dort die Applocker-Regeln nicht auf diesem üblichen Weg einstellen.
jein. ab Oktober Update 2022 unterstützt/übernimmt die Pro auch Applocker aus der Gruppenrichtlinie. vor dem Update ging es nur über Intunes/MDM, wenn es keine Enterprise war
Zu "1" und "2" "(SRP/Safer, Applocker V2)":
Das war ein Missverständnis.
Die Applocker-Regeln werden in der Registry dort gespeichert:
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\SrpV2
Daraus folgt:
Applocker ist "SrpV2".
SRP war demzufolge "SrpV1", nach Microsoft-Lesart.
Daher die 1 und die 2.
In dem Script hier ist aber etwas anderes gemeint bei "AppLockerPolicy Version='1'".
Wenn man die Applocker-Regeln als XML speichert, dann steht in der ersten Zeile eben dieser Text drin.
Zitat:
" Bei Microsoft das sind Idioten, Teams.exe und Onedrive.exe liegen in %userprofile_appdata und werden mit den Standardregeln gesperrt. "
—
Der TOR Browser ab Version 14 macht das leider auch so.
Wenn man den dann in den Programmordner kopiert, dann funktioniert er nicht mehr richtig, weil ihm Schreibrechte fehlen und er nicht auf den User-Ordner ausweicht.
Bei Version 13 war das noch nicht der Fall.
Man kann im Applocker auch nicht alle 8 exe des TOR in einer Regel erlauben, sondern ich muss da 4 Regeln anlegen, weil die 8 exe in 4 Ordnern gespeichert sind.
2. Zitat:
"auch das kaum beachtete schtask (schtask.exe slash-run "beliebige.exe" umgeht Applocker!!!,"
—
Da fehlt ein s am Ende des Dateinamens.
schtasks.exe
3.
Nicht vergesen, diese Ordner zu sperren:
%HOT%
%REMOVABLE%
(etwa für USB-Sticks mit Auto-RUN-Funktion)
%OSDRIVE%\Users\USERNAME\Desktop\*
%WINDIR%\Temp\*
%OSDRIVE%\Users\USERNAME\AppData\Local\Temp\
Bei mir habe ich auch den Temp-Ordner des Admin-Accounts gesperrt.
Den muss ich aber immer vorher wieder öffnen, wenn ich mal mit dism arbeite.
Die Verzeichnisse in %OSDRIVE%\Users\ muss man nicht explizit sperren, weil man sie ja nicht freigegeben hat. %HOT% und %REMOVABLE% deswegen eigentlich auch nicht, aber mir scheint, du hast Einblick in meine Applocker-Regeln, die ich so bei dutzenden Kunden erstellt habe, da gehört das sicherheitshalber auch zu den Standardregeln (um die möglicherweise freigegebenen Netzlaufwerken zu unterscheiden). Die von dir genanten Unterverzeichnisse in %WINDIR% werden rauspurzeln, wenn du AccessEnum, Evasor oder die erwähnten Scripte zur Ermittlung von userbeschreibbaren Verzeichnissen laufen lässt.
Ob man den Tor-Browser im Enterprise-Umfeld einen Anwendungsfall hat? Ich möchte den nicht im Netz haben.
Applocker ist im Gegensatz zu SRP ein Enterprise Feature gewesen, es gibt im Gegensatz zu SRP ein Monitoring.
wer kein zentrales Eventlogging hat, kann das schnell mit WEF lösen. du solltest auch nicht nur einen Rechner testen, sondern viele. deswegen gibt es ja das Audit.
Stefan hat mit seiner LOOPHOLE.exe ein Werkzeug, um die Lücken in vermeintlich sicheren Ordnern zu finden.
diese müssen als Pfad Ausnahme "\*" eingetragen werden und zusätzlich als ADS, Alternate Data Stream ":\*". Letztere werden sonst weiterhin ausgeführt.
wenn du jetzt noch die Admins schützen möchtest, das sie nicht Mal eben schnell Software installieren, muss man nur die Regel wer Alles darf entfernen, oder anpassen. dann muss man schon NT authority System sein, oder "Helpdesk"
(natürlich kann der Admin es umgehen, aber dann muss er wissen, wie er System wird)
Ist der Backslash bei Alternativen Datenströmen wichtig oder egal?
Bei Stefan Kanthak steht es ohne Backslash, bei dir aber mit Backslash.
"PFAD:*"
versus
"PFAD:\*"
entschuldige, Tippfehler.
es ist :*
Ergänzungen:
1.
Der Dienst "Anwendungsidentität" (AppIDSvc) muss per Registry von "manuell" auf "automatisch" umgestellt werden. Diese Umstellung direkt im Dienste-Dialog funktioniert nicht und mit der Standard-Einstellung "manuell" schaltet sich dieser zwingend notwendige Dienst beim nächsten Neustart wieder aus und Applocker ist dann inaktiv.
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\AppIDSvc]
"Start"=dword:00000002
2.
Im Gruppenrichtlinieneditor (gpedit.msc) müsen die 4 Optionen "Regel erzwingen" aktiviert sein:
Computerkonfiguration,
Windows-Einstellungen,
Sicherheitseinstellungen,
Anwendungssteuerungsrichtlinien,
Applocker
"Regelerzwingung konfigurieren" anklicken.
Im Reiter "Erzwingen" die 4 Kästchen anhaken.
In den 4 Zeilen jeweils unterhalb dieser angehakten Kästechen die Option "Regeln erwingen" einstellen.
OK klicken.
Vorsicht bei den DLL-Regeln, die sollte man nur als fortgeschrittener Applocker-Admin verwenden, auch hier gillt: Testen, testen, testen… Man kann sich mit den DLL-Regeln ordentlich ins Knie schießen! Erstmal alles andere ans Laufen zu bekommen ist erstmal genug und dürfte 99% Dreck abfangen.
Im März habe ich wieder bei einem Kunden ein Projekt, um Applocker endlich einzuführen, wir bieten es ihm schon seit Jahren an, wollte aber nicht. "Antivirus reicht". Resultat, neues Jahr, neue Mitarbeiterin wusste noch nicht, wie sie an PDF-Software ran kommt, lädt sich was per Google passend gefundenes runter, startet, paff, zum Glück nur teile des Benutzerprofils verschlüsselt, bevor der Antivirus den Vorgang gestoppt hat, zum Glück nicht mehr. Gab wohl gleich eine Abmahnung.
ohne DLL Regeln hat du nicht nur Löcher im Zaun, sondern Tore.
Das ist wie .exe sperren, aber .com Dateien ignorieren.
.com sind MS-DOS 16-Bit-Excuteables. Die unterstützt ein 64-Bit Windows garnicht mehr.
Die DLL-Regeln halte ich nicht für zwingend erforderlich und es gibt auch Alt-Software, die manchmal noch eingesetzt werden muss, die damit nicht funktioniert.
es war ein Beispiel, um dir die Gefahr von DLLs näher zu bringen.
.com Dateien werden auch unter x64 ausgeführt, du kannst dir welche bei Stefan runterladen. ;-)
wie die ausführbare Datei heißt, bestimmt der Angreifer. das hat nichts mit der Architektur zu tun. MS führt sie aus
Bitte ändere deine Einstellung zu DLLs, für schlechte alte Software gibt es "gute" Regeln.
Das Script Eleven.xml im weiterführenden Link enthält einige Pfade, die bei mir bisher noch nicht gesperrt waren.
Alle Pfade mit einem Doppelpunkt am Ende, DeviceIcons, "AppCache.", Storage, StartupInfo.
Diese hatte die Dummy.cmd Testdatei zur Ermittlung der beschreibbaren Ordner bei mir nicht gefunden (Win10 21H2 LTSC).
Wurden diese Ordner erst mit Windows 11 eingeführt?
Was ist überhaupt der Sinn von Ordnern, die einen Doppelpunkt enthalten?
War sowas früher nicht verboten in Pfaden?
Warum baut Microsoft bei "AppCache." noch einen Punkt in den Pfad ein?
Was soll das?
Kann ich dir nicht sagen. Doppelpunkte sind in Datei- und Ordnernamen eigentlich unzulässig.
NTFS Alternate Data Stream. du kannst an einen Pfad/Datei einen alternativen Befehl anhängen und diesen zb per WMIC oder anderem Tool ausführen.
type C:\temp\evil.exe > "C:\Program Files (x86)\TeamViewer\TeamViewer12_Logfile.log:evil.exe"
wmic process call create '"C:\Program Files (x86)\TeamViewer\TeamViewer12_Logfile.log:evil.exe"'
https://github.com/api0cradle/UltimateAppLockerByPassList/blob/master/Generic-AppLockerbypasses.md
Ordner, die "fehlen":
einige kommen erst mit der Installation der Windows Feature, deswegen findet man sie nicht in einer "Blanko Install" von CD/ISO.
der Twain Ordner zb kommt AFAIR erst mit Fax und Scan. ich habe es nie durchgetestet. am Ende muss man regelmäßig die freigegebenen Ordner der Standardregeln prüfen. es kann sich zur Laufzeit was ändern.
So eine Antwort war zu erwarten.
Grüße aus dem Teich der anonymen Frösche.
Welcher Punkt ist falsch und warum und wie geht es richtig?
Dieses ständige "sich zoffen" statt "zu erklären" ist uns nun zu viel, sind dann mal weg! Anstatt euch zu streiten solltet ihr mal lieber die "Köpfe zusammenstecken" und das Ergebnis zu Verfügung stellen.
"Doswidanja"
Zu:
"ich antworte prinzipiell nur Menschen, die ihren vollen Namen schreiben"
Auch wenn in der Kommentarfunktion ein vollständiger Name angegeben wird,
garantiert dieses nicht die echte, offizielle Identität einer Person.
Den Einwand verstehe ich daher nicht.
Ich habe jetzt zwei Kommentare von Stefan Kanthak gelöscht, da sie nicht mehr zielführend, sondern beleidigend waren. Bin sogar am überlegen, den Beitrag zu löschen. Was mal als Tipp gedacht war, entwickelt sich durch die Antworten von Stefan zu toxischen Kiste. Brauche ich hier im Blog definitiv nich!
S.K. hat zwar viele hilfreiche Beiträge erstellt, aber Kritik kann er nicht ab. Man sieht es auch bei seinen Beiträgen auf Full-Disclosure. Da sind alle anderen immer Idioten, natürlich auch die Leute in Redmond, die es verbockt haben. Drunter gehts bei ihm nicht. Er ist natürlich unfehlbar.
Mein Beitrag mit dem Froschteich kann auch weg, der ist jetzt aus dem Zusammenhang gerissen.
Und um S.K. glücklich zu machen: Mein realer Name ist Hans Meiser. :-P
wenn es um grundlegende, offensichtliche Fehler und schlicht dumme, unsinnige Fehlkonfiguration geht, formuliert jeder von seinem Standpunkt des Wissens:
> Bei Microsoft das sind Idioten, Teams.exe und Onedrive.exe liegen in %userprofile_appdata (…)
P. S. es ist übrigens %localappdata% ;-)
@Mark: Ich schätze Stefans Expertise – da werde ich nie hin kommen. Das war auch der Grund, warum ich über die Jahre seine Einwürfe bestmöglich aber meist schon gefiltert hier in den Blog eingestellt habe. Auch kenne ich etwas seine persönliche Situation, die hier nicht hin gehört.
Wenn er gegen mich ranted, ist mir das schnurz egal. Aber es geht schlicht nicht, wie er die Leser hier angeht. Das macht mir den Blog kaputt – und die drei Jahre Auslaufmodus möchte ich den Brass eher zurückdrängen als befeuern. Daher habe ich jetzt rigoros Kommentare von ihm gelöscht.
Es ist wie es ist, letztendlich sitze ich immer zwischen den Stühlen. Aber es gibt eine Grundmasse an Lesern, die ihre Positionen und ihre Erfahrungen sauber in Kommentaren rüber bringen, ohne das Gegenüber herabzuwürdigen. Und dann profitiert die Leserschaft.
ich weiß. ich stecke regelmäßig ein :-)
es ist dein Blog, du machst es schon richtig
Besser als zuvor auf jeden Fall!
Toxisch sind die VÖLLIG falschen, vor Fehlern und Unwahrheiten strotzenden Kommentare, die hier wieder einmal in der Überzahl sind: wenn man keine Ahnung hat…
Stefan, lass gut sein. Wenn Du was falsches sachliche korrigierst, ist das kein Problem. Wenn es auf Pöbeleien raus läuft, lösche ich, ganz einfach.
@Günter
Meine Bitte:
Lösche diesen Blogbeitrag komplett und zugünftig keine Blogbeiträge mehr mit Verweis auf Stefan Kanthak.
Danke!
Erster Teil des Satzes -> "vorerst nein, es ist eine Diskussion einiger Leser um die Thematik entstanden, die ich für die Leser erhalten möchte", zweiter Teil des Satzes -> diese Entscheidung hatte ich bereits vorher getroffen – ist zwar schade, geht aber offenbar nicht anders.
btw: Toxisch sind die VÖLLIG falschen, vor Fehlern und Unwahrheiten strotzenden Kommentare, die hier wieder einmal in der Überzahl sind: wenn man keine Ahnung hat…
btw: Es ist DEIN Blog; ich korrigiere hier kein mit Fehlern und Lügen gespicktes dummes Geschwätz Ahnungsloser, die nicht mal ihren eigenen Namen schreiben können!
Lösungsansatz:
Ignorriere einiges und korrigiere anderes. Freundlichkeit beginnt mit der Einsicht, dass wir alle nicht perfekt sind.
Für einen Otto Normalverbraucher zu Hause ist das nicht machbar.
Für den ist das auch nicht gedacht. Es gibt von der c't ein einfacheres Tool für die Software Restriction Policy. Aber bitte auch das nur mit Vorsicht einsetzen. Erstmal Backup…
https://www.heise.de/hintergrund/Restric-tor-Profi-Schutz-fuer-jedes-Windows-3690890.html
Man sollte aber vor Anwendung des Tools den Artikel aus der c't lesen!
Kwatsch: siehe https://skanthak.hier-im-netz.de/SAFER.html
Sowohl das Skript https://skanthak.hier-im-netz.de/download/AppLocker.wsf als auch meine seit über 20 Jahren bereitgestellten, ebenfalls mit EINEM Mausklick ausführbaren Skripte https://skanthak.hier-im-netz.de/download/XP_SAFER.INF, https://skanthak.hier-im-netz.de/download/NT6_SAFER.INF und https://skanthak.hier-im-netz.de/download/NTX_SAFER.INF sind explizit für Otto Normalmissbraucher gemacht!
Das traut sich kein Otto Normalmissbraucher. Die verstehen das nicht mal. Wenn dann musst du was in Clickbunti-Klick.exe machen oder das in Schlangenöl wie CCcleaner einbauen lassen. Und der Spezialist sagt: Besser keine fremden Scripte ungeprüft laufen lassen. Und Schlangenöl schon garnicht.
AppLocker führt den Personal Computer ad absurdum. Admins Computer wäre der bessere Name. In Zeiten des Mainframes mit Terminals hatte der Benutzer ähnlich beschränkte Möglichkeiten. Die heutige Corporate IT dreht das Rad um 40 Jahre zurück. Fortschritt ist Fehlanzeige. Außer Restriktionen fällt diesen nichts ein, statt ihre Microsoft/Windows Religion mal auf den Prüfstand zu stellen.
Kann man so sehen. Aber es herrscht Krieg. Nicht nur da draußen, sondern auch auf den PCs. Es gibt genügend Kriminelle, die nur dein Bestes, oder das Beste von deinem Arbeitgeber haben will. Nämlich euer Geld, durch Erpessung, in denen sie Daten verschlüsseln und den Entschlüsselungscode verkaufen wollen. Oder in dem sie die geklauten Informationen verkaufen, an dich, an die Öffentlichgkeit, an den Mitbewerber, usw. Oder es geht schlicht um "Zerstörung". Und Windows ist numal direkt nach der Installation leider ein ziemlich offenes System. Entweder weiß der Benutzer, was er tut, oder er muss vor sich selbst geschützt werden.
Du sprichst das Problem direkt an: Windows. Und dennoch halten die meisten in quasi religiösem Eifer daran fest, anstatt Microsoft den Rücken zu kehren und damit zu zeigen, so geht das nicht. Ich will daß Fass gar nicht aufmachen, ob MacOS, GNU/Linux oder sonstwas besser ist. Tatsache ist, Windows ist schlecht und Microsoft tut nichts als KI darüber kippen und weiter kassieren.
Es gibt Menschen wie ich, die sind seit dem Bestehen des Internets in Deutschland (und noch davor zu Mailbox Zeiten) mit Computern und netzwerken unterwegs. Die wissen ziemlich genau, was sie tun und werden dennoch gegängelt, wie technische Idioten. Da wird es zum Sport, die Versuche der Admins sie einzuhegen, ins Leere laufen zu lassen und die Maßnahmen zu umgehen. Das halte ich für gefährlich. Wenn man den Fachleuten nicht zutraut mit der Technik richtig umzugehen, dann ist das IMHO ein Sicherheitsrisiko, das sich mit Schlangenöl und Co. nicht beherrrschen läßt.
Wenn es so schlecht wäre, würde es kaum noch jemand benutzen. Man bekommt all das Sicherheitsthema größtmöglichst in den Griff, man muss es halt nur machen, das ist Arbeit, und von der leben auch wir Admins. Und auch schon Admins und seit Commodore/Atari/…-Zeiten aktive Nutzer sind auf Scams reingefallen, niemand ist unfehlbar.
Frage 1:
Kann man Applocker gegen die Umgehung durch Alternate Data Streams schützen, indem man folgenden Pfad in einer Applocker-Regel benutzt, oder gibt es einen Grund, warum man das so nicht machen sollte:
*\*:*
Frage 2:
Warum sind in dem Eleven.xml folgende Pfade nicht zusätzlich gegen Alternative Data Streams geschützt?
Ist das nicht nötig oder wurde das vergessen?
%WINDIR%\System32\AppLocker\AppCache.*
%WINDIR%\System32\WDI\LogFiles\StartupInfo\*
skanthak. hier-im-netz. de/ten.html#eleven
1.) pauschal kann Applocker das nicht
2.) ich habe mir das XML nicht komplett angeschaut, ich nutze ein eigenes/anderes, würde aber auf "vergessen" tippen, wenn der Pfad ansonsten genannt ist
Auch Du, Brutus^WMark?
SELBSTVERSTÄNDLICH habe ich NICHTS vergessen/übersehen!
jetzt bin ich gespannt, warum sie nicht genannt sind, wenn der Benutzer die ändern darf ?
Weiß nicht, ob Stefan in der Lage oder Willens ist, vernünftig zu antworten (falls ja, bleiben die Kommentare natürlich stehen). Aber die letzten Kommentare von ihm habe ich schlicht gelöscht, weil im gleichen Duktus, wie bisher waren. Er drückt sich so aus, dass er in meinem Blog falsche Darstellungen nicht korrigiert – ist ja ok. Wenn es halt mit Beschimpfungen der Leserschaft einhergeht, lösche ich. Fertig.
Du verwechselst ganz offensichtlich Lesen und Schreiben: dass Du in Deinem Blog von Ahnungslosen verzapften Unsinn stehen lässt ist SEHR bedauerlich!
Wie wär's mit einem Faktencheck?
Stefan: Wenn Du einen Fehler siehst, und sachlich darauf hin weist, am besten mit Link, wo es erklärt wird, bleibt das stehen. Wenn Du Leser herabwürdigst oder nur "ich antworte nicht auf Kinder, die nicht mal ihren eigenen Namen schreiben können", ist das wenig zielführend im Sinne dessen, was ich mit dem Blog anstrebe. Du bist gerne eingeladen, fehlerhaftes sachlich klarzustellen. Wo ich ab sofort rigoros lösche, sind Kommentare, die dem nicht entsprechen und vom Duktus der Diskussion nicht gut tun, weil Leute als unwissend oder dumm herab gewürdigt werden. Damit bin ich aus der Diskussion raus – der Ball liegt bei dir im Spielfeld.
Falsch: es ist DEIN Blog^WSpielfeld, Du SOLLTEST die vor Fehlern und Unwahrheiten strotzenden, völlige Unkenntnis der Materie offenbarenden Kommentare einiger Schreiber löschen!
Es fehlt eine Begründung, warum manche Ordner angeblich nicht vor einer Änderung der Alternate Data Streams geschützt werden müssen.
Ich verstehe so ein Mysterium nicht, würde es aber gerne verstehen.
Bisher stehe ich auf dem Standpunkt es gilt für alle beschreibbare Ordner, denn ich sehe da kein Differenzierungskriterium.
Ok, wenn man am Rechner schaut und nicht allein auf das Telefon im Schnee angewiesen ist, dann lautet meine Antwort:
Der \StartupInfo Ordner ist nicht das Problem, es sind die XML Dateien darin. Diese sind nach dem Schema "SID_StartupInfo1-5.xml" gebaut. Diese können aufgrund der benutzerspezifischen SID nicht in das Regelwerk eingebaut werden. Da bin ich dann wieder bei der Korrektur der NTFS Rechte.
Die Appcache.dat/Appcache.dat.log1/Appcache.dat.log2 betrifft den ersten Benutzer unter Applocker am System :-)
https://oddvar.moe/2019/05/29/a-small-discovery-about-applocker/
-> 3 Einträge oder Korrektur NTFS Rechte.
Danke für diese Erklärung.
Zu Appcache.*
Es sind also ADS für 3 Dateien gemeint, die gar nicht bschreibbar sein dürften, die in einem Ordner liegen, der gar nicht beschreibbar sein dürfte und Stefan Kanthak hat alles mit Wildcard abgekürzt, unter Weglassung des Doppelpunkts (als ADS-Kennzeichnung).
Also da muss man erstmal drauf kommen.
Die 3 Dateien Appcache.dat* sind also (nur) für den ersten User beschreibbar, obwohl der Ordner nicht beschreibbar ist?
Wie kann denn sowas sein?
Kann eigentlich nicht sein und der Ordner muss ebenfalls geblockt werden, so wie es im verlinkten Artikel steht, aber im Eleven.xml von Stefan Kanthal fehlt das.
%WINDIR%\System32\AppLocker\*
%WINDIR%\System32\AppLocker:*
Die ADS an den 3 Dateien müssten eigentlich wie folgt gesperrt werden:
%WINDIR%\System32\AppLocker\AppCache.dat:*
%WINDIR%\System32\AppLocker\AppCache.dat.LOG1:*
%WINDIR%\System32\AppLocker\AppCache.dat.LOG2:*
Auf die Idee, das alles rotzfrech mit Asterix abzukürzen (Appcache.*) wäre ich nicht gekommen, weil ich den Doppelpunkt nicht als normalen Namensbestandteil ansehe, sondern nach dessen Funktion her eher vergleichbar zu einer Pipe.
Ich hätte da Angst, dass durch den einen Asterix nur normale Dateien erfasst werden, aber nicht zusätzlich auch noch jeweils deren diverse ADS.
Wenn ein Asterix wirklich auch den Doppelpunkt ersetzen kann, warum wird der Doppelpunkt dann nicht generell bei allen Applocker-Regeln bezüglich Alternate Data Streams weggelassen?
Man schreibt bei Dateien ja auch "*.*" und nicht nur "*", man lässt also nicht einfach den Punkt weg.
Wie viele solcher Lücken (Backdoors) mit beschreibbaren Dateien und Ordnern, die eigentlich nicht beschreibbar sein dürfen, gibt es in Windows noch?
Bei jedem beliebigen Update kann Microsoft die Rechte an irgend einer Datei oder Ordner verbiegen, wodurch dann ADS-Anhänge möglich werden und der Applocker ist im Eimer.
NEIN, EIN Eintrag: …\AppCache.* oder das äquivalente …\AppCache.dat* wirkt für alle Pfade, die damit beginnen, also AppCache.dat:‹ADS›, AppCache.dat.log1:‹ADS› und AppCache.dat.log2:‹ADS›
JFTR: "perfekt ist, wenn man nichts mehr wegnehmen kann" (Antoine de Saint-Exupery)
Ich empfehle AUSDRÜCKLICH die Lektüre von https://skanthak.hier-im-netz.de/whispers.html#whisper3, https://skanthak.hier-im-netz.de/whispers.html#whisper4 und https://skanthak.hier-im-netz.de/whispers.html#whisper5 sowie https://skanthak.hier-im-netz.de/comspec.html und https://skanthak.hier-im-netz.de/blunder.html, selbstverständlich inklusive Ausführung der Demonstrationen.
noch mal geschaut:
Die Berechtigung auf der appcache.dat Datei wird für den ersten lokalen Benutzer mit der RID -1000 gewährt.
Das ist bei einer Neuinstallation Windows 11 25H2, der in der OOBE erstellte defaultuser0. Dieser wird nach Anmeldung des ersten manuell erstellten Users (oder Domänen Benutzer) wieder gelöscht.
Das Recht zum Editieren der Datei ist nur für diesen User RID-1000 gesetzt, die ACL verweist anschliessend auf eine verwaiste SID.
Der Angriff über Appcache.* dürfte im AD/Domänenbetrieb und in Neuinstallationen nicht mehr möglich sein.
0) "defaultuser0" kann eine RID grösser -1000 haben; wie das passiert habe ich Dir neulich erklärt!
1) Bei Upgrade-Installationen bleibt die Schwachstelle bestehen!
Ich finde diesen Artikel hier sehr hilfreich, weil er mir Lücken in meinen Applocker-Regeln gezeigt hat.
Der Schutz gegen Alternate Data Streams ist notwendig, denn dort sind 15 Methoden aufgelistet, wie man Schädlinge als Alternative Datenströme mit Bordmitteln anhängen kann:
gist. github. com/api0cradle/cdd2d0d0ec9abb686f0e89306e277b8f
Die WMIC hatte ich bereits vorher gesperrt und irrtümlich angenommnen, damit sei diese Umgehung mittels ADS ausreichend versperrt, aber das stimmt nicht.
Die anderen Methoden kann man kaum sperren, weil man diese Befehle manchmal braucht.
Deswegen ist die Sperre mittels des angehängten Doppelpunkts in den Pfadregeln die bessere Methode.
Diese Methode hatte ich nicht auf dem Schirm, das war ein blinder Fleck.
Das fehlt auch in vielen Anleitungen zum Applocker, die ich bisher gelesen hatte.
Es fehlt ein Tool von Microsoft zur Konfigurierung des Applockers, wo auch diese Methoden zur Umgehung des Applocker mit erfasst sind:
– Anwendungsidentität-Dienst muss auf automatik eingestellt sein
– Regel-Erzwingung muss aktiviert sein
– automatische Erfassung aller Ordner mit Schreibberechtigung im Windows- und Programme-Ordner
– Mock-Ordner mit Space im Root-Ordner ("Windows " und "Program Files "). Muss mit Änderung der NTFS-Rechte blockiert werden.
takeown /f C:\ /a
icacls.exe C:\ /deny "VORDEFINIERT\Benutzer":(ad,wd)
ICACLS C:\ /setowner "NT SERVICE\TrustedInstaller"
– Alternative Data Streams
Der Gruppenrichtlinienditor ist dafür nicht umfassend geeignet.
Der Applocker ist zwar eine sehr gute Schutzfunktion, aber es gibt auch verdächtig viele Lücken zur Umgehung des Applockers.
Da muss man Microsoft schon Absicht unterstellen, das sowas nicht mal längst gefixt worden ist.
ich sehe/gehe einen anderen Weg zum Schutz vor Alternate Data Streams: ich korrigiere die NTFS Rechte. das geht auf Dateien und Ordnern sehr einfach per GPO.
ich nehme ihn Kauf, das ein Benutzer DSM evtl keinen Task mehr erstellen kann, soll er in einem AD aber idR auch nicht.
Nachteil:
ich mische Technik. Applocker und Security CSE, NTFS. ich habe evtl unerwünschtes Verhalten, mangels Schreibrecht des Benutzers. da habe ich aber noch keines gefunden.
Vorteil: das Regelwerk ist einfacher und Admins können mit NTFS rechten leicht umgehen, somit geringerer Schulungsaufwand
de facto habe ich aktuell beides in meiner Applocker GPO :-)
Zitat:
"ich sehe/gehe einen anderen Weg zum Schutz vor Alternate Data Streams: ich korrigiere die NTFS Rechte."
—
Wie genau machst du das, also welche Rechte änderst du wie?
Meinst du das Recht "Erweiterte Attribute schreiben"?
Das "Mark of the Web" ist auch in einem Alternate Data Stream gespeichert.
Funktioniert das MotW noch nach deiner Änderung?
ich nutze die Sicherheitsoptionen/Dateisystem. Die UI bietet dir dann eine Rechte Schablone an, diese ist nicht 100% genau und perfekt, wenn man es in der .inf als ACL betrachtet, sie funktioniert aber. ich vergebe für Benutzer nur Leserechte.
Mark of the Web:
nein, das geht auch nicht, da es keine schreib Rechte gibt, aber unter %windir% sollte das nicht benötigt werden
ich nutze die Sicherheitsoptionen/Dateisystem. Die UI bietet dir dann eine Rechte Schablone an, diese ist nicht 100% genau und perfekt, wenn man es in der .inf als ACL betrachtet, sie funktioniert aber. ich vergebe für Benutzer nur Leserechte.
Hab mir jetzt mal die Mühe gemacht und mir den Artikel, die ganzen Links usw. auch angesehen. Und ich gehe mit dem Fazit, dass die Anleitung in der Form wie sie von SK übernommen wurde, unbrauchbar ist, mit. Die Nicht-Existent einer Regel für die beiden Program-Files Ordner ist dabei nur ein grober Schnitzer, der derart misshandelte PCs quasi unbrauchbar macht. Selbst die Windows-Installation selbst spült schon einige Software in den Pfad, die dann von angemeldeten Benutzern nicht verwendet werden kann. Und auch Regeln für die "Apps" fehlen völlig, wer will denn schon z.B. auf Outlook-New verzichten? *scnr* Und der Laie, der das Script anwenden soll, weiß dann nicht mal, was fehlt und kann es nicht reparieren. Die Leserbeiträge von Mark, Gänsi und Bolko sind sehr hilfreich und zeigen, dass das Thema kein Zuckerschlecken ist wo man einfach mal ein (ungeprüftes und unverstandenes) Script rennen lässt um seinen PC zu härten, so dass er für nix mehr zu gebrauchen ist. Über den anderen Kommentator lege ich mal den Mantel des Schweigens. *facepalm*
Fazit: Finger weg, wenn man nicht weiß was man da tut und auch keinen Spaß daran hat, sein System ständig wieder neu aufzusetzen.
Da muss ich dich korrigieren:
Siehe Punkt 2 in Stefans Anleitung https://skanthak.hier-im-netz.de/applocker.html auf den Günter verlinkt.
Das von Stefan bereitgestellte Regelwerk als XML -> https://skanthak.hier-im-netz.de/ten.html#eleven , das im oben Artikel genannten Snippet als Replace für "" eingetragen wird enthält:
für DLL, EXE und SCRIPTS.
Applocker kennt andere Variablen als das OS und benutzt nur eine Variable für beide Ordner.
Die von Microsoft bereitgestellten Applocker Standard Regeln sind natürlich integriert. Sie haben kleine Anpassungen erhalten, die in einer Workgroup Bedingung genauer definieren, für wen die Regel gilt.
S-1-1-0 (Jeder) ist ersetzt durch S-1-5-113 (Lokales Konto) (1)
S-1-5-32-544 (Administratoren) ist ersetzt durch S-1-5-114 (Mitglied der (Lokalen) Administratoren)
Ebenfalls sind APPS mit MS Standard zugelassen: "muss signiert sein", was eine grundsätzliche Vorgabe für APPS ist, als Ausnahme gibt es eine Regel für(gegen) Copilot
(1) in der Domäne würde ich S-1-5-32-545 oder S-1-5-*domainSID*-513 (Benutzer) verwenden.
Da hat der HTML Kommentar Editor zugeschlagen:
[…] als Replace für "AppLockerPolicy Version='1'" eingetragen wird enthält: FilePathCondition Path='%PROGRAMFILES%\*'
Der Editor hat die Texte zwischen "" entfernt
Fazit: Da geht nichts kaputt ;-)
Es wird aber auch nicht viel besser. Den auf unverwalteten PCs, daheim zum Beispiel, sind die Leute üblicherweise lokale Admins. Solange die – von Microsoft – automatisch angelegte Adminregel für "alles" vorhanden ist, nützt einem der ganze getriebene Towubahohu goarnix.
Keiner kann die Leute retten, die nicht gerettet werden wollen.
Die Links lesen und der Anleitung folgen:
-> 6. Log on to an (unprivileged) standard user account […]