Zum Inhalt springen
05 · AnwendungssteuerungTeil 4 von 4Fortgeschritten

AppLocker-Rollout: Skripte, Installer und App-Pakete

AppLocker sicher ausrollen: Dienst Anwendungsidentität, Überwachungsmodus, Herausgeberregeln für EXE, Skripte, MSI und App-Pakete sowie Lücken in beschreibbaren Ordnern.

Florian Amette7 Min. Lesezeit

Der Grundlagenleitfaden zu App Control empfiehlt App Control for Business als geräteweite Basis und behält AppLocker für das, was es weiterhin gut kann: benutzer- und gruppenbezogene Regeln, schnelle Erfolge auf Systemen, auf denen App Control noch nicht einsatzbereit ist, und das Blockieren der klassischen, für Benutzer beschreibbaren Startpunkte. Dieser Leitfaden beschreibt den vollständigen AppLocker-Rollout, Sammlung für Sammlung, mit den Überwachungsdaten, die verhindern, dass er den Geschäftsbetrieb stört.

AppLocker ist nicht veraltet. Es erhält Sicherheitskorrekturen, aber keine neuen Funktionen, und wird im Benutzermodus durch den Dienst Anwendungsidentität durchgesetzt. Behalten Sie beides im Hinterkopf: AppLocker ist leicht bereitzustellen und für jeden mit Adminrechten leicht zu untergraben. Es gehört daher mit dem Entzug lokaler Adminrechte zusammen.

Die fünf Regelsammlungen

SammlungDateitypenStandardregeln erlauben
Regeln für ausführbare Dateien.exe, .comJeder: %PROGRAMFILES%\*, %WINDIR%\*; Administratoren: alle Dateien
Windows Installer-Regeln.msi, .msp, .mstJeder: alle digital signierten Installer, %WINDIR%\Installer\*; Administratoren: alle Dateien
Skriptregeln.ps1, .bat, .cmd, .vbs, .jsJeder: %PROGRAMFILES%\*, %WINDIR%\*; Administratoren: alle Dateien
Regeln für App-Pakete.appx, .msix (Installation und Ausführung)Jeder: alle signierten App-Pakete
DLL-Regeln (optional).dll, .ocxJeder: %PROGRAMFILES%\*, %WINDIR%\*; Administratoren: alle Dateien

Jede Sammlung hat eine eigene Erzwingungseinstellung. Eine Sammlung ohne Regeln wird nicht erzwungen, und eine mit Regeln, aber ohne Erzwingungseinstellung wird erzwungen. Dieses zweite Verhalten überrascht viele: Setzen Sie den Modus immer ausdrücklich.

Es gibt drei Regeltypen: Herausgeber (Signaturgeber, Produkt, Dateiname, Version), Pfad und Datei-Hash. Bevorzugen Sie Herausgeberregeln; sie überstehen Updates. Verwenden Sie Pfadregeln nur für Ordner, in die Standardbenutzer nicht schreiben können.

Schritt 1: Voraussetzungen

  • Dienst Anwendungsidentität auf Automatisch gesetzt. Verwenden Sie Computer Configuration > Policies > Windows Settings > Security Settings > System Services > Application Identity. In aktuellen Windows-Versionen können Sie den Starttyp nicht in der Dienste-Konsole ändern; die Richtlinie ist daher der zuverlässige Weg.
  • Unterstützte Edition. AppLocker wurde früher nur auf Enterprise-, Education- und Server-Editionen erzwungen. Seit KB5024351 erzwingen Windows 10 ab 2004 und alle Versionen von Windows 11 es auf jeder Edition, auch auf Pro. Auf älteren Builds (einschließlich Windows Server 2019) funktionieren per Gruppenrichtlinie verteilte Richtlinien nur auf Enterprise- und Server-Editionen, während per MDM verteilte Richtlinien auf allen Editionen funktionieren.
  • Eine Pilot-OU mit einer repräsentativen Auswahl an Benutzern: Finanzen, Entwicklung, Helpdesk und, falls vorhanden, ein gemeinsam genutzter Kiosk.

AppLocker-Regeln befinden sich unter Computer Configuration > Policies > Windows Settings > Security Settings > Application Control Policies > AppLocker. Auf mit Intune verwalteten Geräten wird die AppLocker-Richtlinie über den AppLocker-CSP als benutzerdefinierte OMA-URI-Einstellungen mit dem XML der Regelsammlung verteilt, ein Knoten pro Sammlung: ./Vendor/MSFT/AppLocker/ApplicationLaunchRestrictions/{Grouping}/EXE/Policy, mit MSI, Script, StoreApps und DLL anstelle von EXE für die anderen Sammlungen ({Grouping} ist ein eindeutiger Name, idealerweise eine GUID).

Schritt 2: im Überwachungsmodus mit vernünftigen Standards beginnen

Öffnen Sie im AppLocker-Knoten Configure rule enforcement und setzen Sie die Regeln für ausführbare Dateien, Windows Installer, Skripte und App-Pakete auf Audit only. Klicken Sie dann für jede Sammlung mit der rechten Maustaste auf Create Default Rules. Standardregeln sind ein Ausgangspunkt, kein Design; zwei Änderungen sind sofort nötig.

Die beschreibbaren Ordner unter %WINDIR% schließen. Die Standardregel „Jeder darf alles unter %WINDIR% ausführen“ umfasst Unterordner, in die Standardbenutzer schreiben können, und macht sie zu Startrampen. Häufige Beispiele:

  • C:\Windows\Tasks
  • C:\Windows\Temp
  • C:\Windows\tracing
  • C:\Windows\System32\spool\drivers\color
  • C:\Windows\System32\Tasks

Fügen Sie diese als Ausnahmen zu den %WINDIR%-Pfadregeln für ausführbare Dateien und Skripte hinzu. Suchen Sie in Ihrem Build mit Sysinternals AccessChk für die Gruppen Users und Everyone nach weiteren, denn die Liste variiert je nach Version und installierter Software.

Bekannte Umgehungs-Binärdateien für Standardbenutzer verweigern. Die Standardregeln erlauben jede signierte Windows-Binärdatei, auch solche, die beliebigen Code ausführen: mshta.exe, wscript.exe, cscript.exe, regsvr32.exe, msbuild.exe und installutil.exe sind häufige Beispiele. Fügen Sie Herausgeber-Verweigerungsregeln für diejenigen hinzu, die Ihre Benutzer nicht brauchen, beschränkt auf Standardbenutzer statt auf Everyone, damit Admin-Werkzeuge weiter funktionieren.

Schritt 3: Überwachungsdaten sammeln und daraus Regeln erstellen

Lassen Sie den Pilot zwei bis vier Wochen im Überwachungsmodus laufen, lang genug, um Monatsabschlussprozesse abzudecken. AppLocker protokolliert unter Applications and Services Logs > Microsoft > Windows > AppLocker:

ProtokollZugelassenÜberwacht (würde blockiert)Blockiert
EXE and DLL800280038004
MSI and Script800580068007
Packaged app-Execution802080218022
Packaged app-Deployment802380248025

Erzeugen Sie Regelkandidaten direkt aus den Überwachungsereignissen auf einem Pilotgerät:

PowerShell
Get-AppLockerFileInformation -EventLog -EventType Audited `
  -LogPath "Microsoft-Windows-AppLocker/EXE and DLL" |
  New-AppLockerPolicy -RuleType Publisher, Hash -User Everyone -Optimize -Xml |
  Out-File .\candidate-exe.xml

Oder aus einem Referenzordner:

PowerShell
Get-AppLockerFileInformation -Directory "C:\Program Files (x86)\Contoso" -Recurse |
  New-AppLockerPolicy -RuleType Publisher, Hash -User Everyone -Optimize -Xml |
  Out-File .\contoso.xml

Prüfen Sie jeden Kandidaten vor dem Import. Überwachungsdaten eines Benutzers, der irgendeinen Download ausgeführt hat, erzeugen eine Regel, die genau diesen Download zulässt. Beschränken Sie Regeln, wo es sinnvoll ist, auf Gruppen: Konstruktionswerkzeuge für GG-Engineering, nicht für Everyone.

Importieren Sie geprüfte Regeln mit Set-AppLockerPolicy -XmlPolicy .\contoso.xml -Ldap "LDAP://CN={GPO-GUID},CN=Policies,CN=System,DC=corp,DC=example" -Merge in das GPO.

Schritt 4: Skripte, Installer und App-Pakete

Skripte. Das Erzwingen von Skriptregeln hat einen wichtigen Nebeneffekt: PowerShell läuft für Skripte und interaktive Sitzungen, die die Richtlinie nicht zulässt, im Constrained Language Mode. Das blockiert die meiste offensive PowerShell, bricht aber auch Admin-Skripte, die aus für Benutzer beschreibbaren Ordnern ausgeführt werden. Legen Sie Admin-Skripte unter einem nur für Admins zugänglichen Pfad ab oder signieren Sie sie, und lassen Sie Anmeldeskripte ausdrücklich zu: Fügen Sie Pfadregeln für \\corp.example\SYSVOL\* und \\corp.example\NETLOGON\* hinzu (nur wenn diese Freigaben ausschließlich für Admins beschreibbar sind, was sie sein sollten). Details finden Sie im Leitfaden zu PowerShell-Protokollierung und CLM.

Windows Installer. Die Standardregel „alle signierten MSIs“ erlaubt Benutzern, jeden signierten Installer auszuführen. Das ist weit gefasst, stützt sich aber darauf, dass die meisten MSIs Rechteerhöhung benötigen. Verschärfen Sie sie zu Herausgeberregeln für Ihren Softwarekatalog, wenn Benutzer niemals selbst etwas installieren sollen.

App-Pakete. Der Standard erlaubt jedes signierte MSIX-Paket, einschließlich jeder Store-App. Wenn Sie steuern wollen, welche Store-Apps laufen dürfen, ersetzen Sie den Standard durch Herausgeberregeln pro Paket; erzeugen Sie sie aus installierten Apps mit Get-AppxPackage | Get-AppLockerFileInformation.

Schritt 5: in Ringen erzwingen

Stellen Sie jeweils eine Sammlung auf Enforce rules um, beginnend mit ausführbaren Dateien, dann Skripten, dann Installern und App-Paketen. Beobachten Sie in jedem Ring weiterhin 8003, 8006, 8021 und 8024 auf Geräten, die im Überwachungsmodus bleiben, und 8004, 8007, 8022 und 8025 auf Geräten mit Erzwingung.

Benutzerbezogene Regeln auf gemeinsam genutzten Geräten

Hier ist AppLocker App Control noch überlegen, denn App Control wendet auf alle Benutzer eines Geräts dieselbe Richtlinie an. Auf gemeinsam genutzten Rechnern wie Empfangstresen, Terminals in der Fertigung, Schulungsräumen und Stationsarbeitsplätzen in der Pflege können Sie verschiedenen Benutzergruppen auf derselben Hardware unterschiedliche Regeln geben:

  • Kiosk- und Schichtkonten: eine kurze Liste von Herausgeberregeln für die Fachanwendung und den Browser, sonst nichts. Keine Skriptregeln über Anmeldeskripte hinaus.
  • Lokale IT- und Helpdesk-Gruppen: zusätzlich ihre Supportwerkzeuge.
  • Administratoren: die Standardregel „alle Dateien“, da sie durch andere Maßnahmen geschützt sind.

Richten Sie jede Regel auf eine Gruppe statt auf Everyone aus und pflegen Sie die Gruppen in Active Directory oder Microsoft Entra ID, damit Änderungen an der Mitgliedschaft keine Richtlinienänderung erfordern. Kombinieren Sie dies mit einer eingeschränkten Shell oder zugewiesenem Zugriff, wenn das Gerät ein echter Kiosk ist.

Was dabei kaputtgeht

  • Installationsprogramme pro Benutzer: Apps, die nach %LOCALAPPDATA% installieren (üblich bei Konferenz-, Chat- und Entwicklerwerkzeugen), werden standardmäßig blockiert. Stellen Sie über Ihr Verteilungswerkzeug eine computerweite Version bereit.
  • Selbstaktualisierer, die neue ausführbare Dateien in für Benutzer beschreibbaren Pfaden ablegen.
  • Anmeldeskripte aus SYSVOL oder NETLOGON, wenn Skriptregeln ohne die obigen Pfadregeln erzwungen werden.
  • Office-Add-ins und Makros, die Skripte in temporären Ordnern aufrufen.
  • Fernsupport-Tools des Helpdesks, die spontan heruntergeladen werden. Installieren Sie ein freigegebenes Tool vorab.

Überprüfen

PowerShell
Get-Service AppIDSvc | Select-Object Status, StartType
Get-AppLockerPolicy -Effective -Xml | Out-File .\effective.xml
Test-AppLockerPolicy -XmlPolicy .\effective.xml -Path "$env:LOCALAPPDATA\Temp\test.exe" -User CORP\jdoe
$ExecutionContext.SessionState.LanguageMode   # ConstrainedLanguage für einen Standardbenutzer, wenn Skriptregeln erzwungen werden

Test-AppLockerPolicy liefert pro Datei und Benutzer Allowed, Denied oder DeniedByDefault zurück und ist daher in Change-Reviews nützlich. Leiten Sie die Ereignis-IDs für Blockierungen an Ihr SIEM weiter; eine Häufung von 8004-Ereignissen bei einem Benutzer bedeutet oft, dass jemand eine Phishing-Payload ausgeführt hat.

Checkliste

  • Dienst Anwendungsidentität per GPO auf jedem Zielgerät auf Automatisch gesetzt
  • Erzwingungsmodus für jede Sammlung ausdrücklich gesetzt
  • Standardregeln erstellt, mit Ausnahmen für beschreibbare Ordner unter %WINDIR%
  • Verweigerungsregeln für Umgehungs-Binärdateien, die Standardbenutzer nicht brauchen
  • Zwei bis vier Wochen Überwachungsdaten vor der Erzwingung ausgewertet
  • Herausgeberregeln bevorzugt, wo möglich auf Gruppen beschränkt
  • Skriptregeln erzwungen, SYSVOL/NETLOGON zugelassen und Admin-Skripte signiert
  • Blockierungsereignisse (8004, 8007, 8022, 8025) weitergeleitet und mit Alarmen versehen

AppLocker ist die schnelle, benutzerbezogene Schicht. Für eine Kontrolle, die lokale Administratoren nicht einfach abschalten können, kombinieren Sie es mit App Control und einem Managed Installer; der Bereich Anwendungssteuerung listet die vollständige Serie auf.

Häufige Fragen

Warum zeigen meine AppLocker-Regeln keine Wirkung?

Fast immer, weil der Dienst Anwendungsidentität nicht läuft. AppLocker wertet Regeln über AppIDSvc aus; ist der Dienst gestoppt, wird nichts erzwungen und nichts überwacht. Setzen Sie ihn über den Knoten System Services eines Gruppenrichtlinienobjekts auf Automatisch, denn in aktuellen Windows-Versionen lässt sich der Dienst nicht über die Dienste-Konsole umkonfigurieren. Prüfen Sie anschließend, ob Ereignisse in den AppLocker-Protokollen erscheinen.

Sollte ich DLL-Regeln aktivieren?

Nicht zu Beginn. DLL-Regeln setzen voraus, dass jede Bibliothek, die eine zugelassene Anwendung lädt, ebenfalls zugelassen ist. Das vervielfacht den Regelsatz und verursacht bei jedem Ladevorgang geringe Performancekosten. Erzwingen Sie zuerst die Regeln für ausführbare Dateien, Skripte, Installer und App-Pakete. Ziehen Sie DLL-Regeln später für Geräte mit festem Zweck in Betracht oder wechseln Sie zu App Control for Business, das DLLs effizienter abdeckt.

Gilt AppLocker auch für Administratoren?

Regeln gelten für diejenigen, auf die sie zielen, aber die Standardregeln erlauben Mitgliedern von BUILTIN\Administrators, alles auszuführen, und ein Administrator kann ohnehin den Dienst stoppen oder die lokale Richtlinie ändern. AppLocker ist eine Kontrolle für Standardbenutzer. Schützen Sie Administratoren mit getrennten Konten, Tiering und App Control for Business, das ein lokaler Admin bei signierter Richtlinie nicht einfach abschalten kann.

AppLocker-Rollout: Skripte, Installer und App-Pakete

Verwandte Leitfäden