Windows Defender Application Control (WDAC): Anwendungssteuerung härten

Was ist WDAC / App Control for Business

Windows Defender Application Control (WDAC) – inzwischen offiziell App Control for Business genannt – kontrolliert präzise, welche Anwendungen und Treiber auf einem Windows-System überhaupt ausgeführt werden dürfen. Statt bekannte Schadsoftware zu erkennen und zu blockieren (der Ansatz eines klassischen AV), dreht WDAC das Prinzip um: Es erlaubt nur explizit vertrauenswürdigen Code und blockiert alles andere per Default. Dieses Allow-Listing ist einer der wirksamsten Härtungsmechanismen gegen nicht vertrauenswürdige Software überhaupt.

Technisch definierst du dazu Policies – meist als XML-Datei – mit Regeln für erlaubten oder blockierten Code. Eine Policy besteht aus zwei Bausteinen:

• Policy Rule Options – globale Schalter, die das Verhalten steuern (z. B. Audit- vs. Enforce-Mode, ob User-Mode-Binaries geprüft werden, ob der Intelligent Security Graph greift).
• File Rules bzw. File Rule Levels – die eigentlichen Vertrauensregeln, die bestimmen, wie Anwendungen identifiziert werden (per Hash, Publisher, Dateipfad usw.).

Warum sich der Aufwand lohnt:

• Schutz vor nicht autorisierten Anwendungen: Nur freigegebene Software startet. Malware, die nicht auf der Allow-Liste steht, läuft schlicht nicht an – selbst wenn sie den AV umgeht.
• Zero-Day-Resilienz: Auch eine brandneue, unbekannte Bedrohung wird geblockt, solange sie nicht explizit erlaubt ist. WDAC kennt keine Signaturen, die erst „nachziehen" müssten.
• Durchsetzung von Unternehmensrichtlinien: Application-Control-Vorgaben aus Compliance- und Sicherheitsrichtlinien lassen sich technisch erzwingen.
• Integration ins Defender-Ökosystem: WDAC arbeitet mit Defender Antivirus, dem Intelligent Security Graph (ISG) und Defender for Endpoint zusammen. Im Audit-Modus liefert es zusätzliche Telemetrie an Defender for Endpoint.

Ein wichtiger Realitätscheck vorweg: WDAC ist ein anspruchsvolles Thema. Fehlerhafte Regeln sperren im Zweifel geschäftskritische Anwendungen aus. Deshalb gilt die eiserne Regel: immer zuerst im Audit-Modus pilotieren, Events auswerten, nachschärfen – und erst dann in den Enforce-Modus wechseln.

Microsoft pflegt zwei fertige Blockierlisten, die praktisch jede WDAC-Strategie ergänzen sollten: die empfohlenen Blockierregeln für Anwendungen (User-Mode-LOLBins) und die empfohlenen Blockierregeln für Treiber (Vulnerable Driver Blocklist). Beide sind weiter unten eigene Kapitel.

Voraussetzungen

WDAC ist tief ins Betriebssystem integriert; einige Funktionen hängen von Windows-Edition und Build ab.

Unterstützte Editionen und Builds:

• Windows Enterprise und Education: ab Version 1903 vollständig unterstützt (inklusive mehrerer aktiver Policies und Supplemental Policies).
• Windows Pro: benötigt ein Update, um App Control for Business per MDM/Intune ausrollen zu können:
  • Windows 10: KB5019959
  • Windows 11 22H2: KB5019980
  • Windows 11 21H2: KB5019961
• Windows 11 SE: wird nur in Education-Szenarien unterstützt.
• Azure Virtual Desktop (AVD): wird unterstützt.
• Auf Serverseite laufen die File- und Policy-Rules-Konzepte auf Windows Server 2016/2019/2022/2025 – einzelne Optionen (z. B. Script Enforcement) sind auf Server 2016 / Windows 10 1607 LTSB allerdings nicht verfügbar.

Weitere Rahmenbedingungen:

• Intune-Registrierung: Für den MDM-basierten Rollout müssen die Geräte in Intune eingebunden sein.
• Endpoint-Protection-Slider: In Intune wird App Control for Business unter Endpoint Security → App Control for Business konfiguriert; die Konfiguration steuert Audit- vs. Enforce-Verhalten.
• Intelligent Security Graph (ISG) setzt aktiven Defender Antivirus + Cloud-Schutz voraus.
• Für Managed Installer brauchst du eine Softwareverteilung (Intune Management Extension oder SCCM/MEMCM).

Unterstützte Geräte und Editionen für App Control for Business

Policy Rule Options

Die Policy Rule Options sind die globalen Schalter einer Policy. Ändern lassen sie sich über den App Control Policy Wizard (GUI) oder das PowerShell-Cmdlet Set-RuleOption. Manche Optionen sind für zukünftige Erweiterungen reserviert oder aktuell nicht unterstützt.

Grundempfehlung: Beginne mit Enabled:Audit Mode. Im Audit-Modus laufen Anwendungen normal weiter, aber WDAC protokolliert jedes Mal ein Event, wenn eine Datei ausgeführt wird, die die Policy eigentlich nicht erlaubt. Aus diesen Events lässt sich die Policy verfeinern (Informationen aus dem Event-Log erfassen und in die bestehende Policy mergen). Erst wenn die Option Enabled:Audit Mode entfernt wird, läuft die Policy im Enforced Mode. Einzelne Optionen ändern das App-Verhalten auch schon im Audit-Modus – deshalb bei jedem größeren Policy-Update gründlich testen.

Table 1 – Policy Rule Options

Empfehlungstabelle: Setting → Ein/Aus

Die folgende Zuordnung ist ein produktionsreifes Profil (orientiert an der „Signed and Reputable"-Vorlage) mit kurzer Begründung. Sie fasst zusammen, welche Optionen man in der Praxis ein- bzw. ausschaltet.

File Rule Levels & Regeltypen

Über die File Rule Levels legst du fest, auf welcher Granularität du Anwendungen vertraust – vom Hash jeder einzelnen Binärdatei bis hinauf zu einem CA-Zertifikat. Die Levels gibst du beim Erstellen/Ändern der Policy im App Control Wizard oder über die PowerShell-Cmdlets an. Jedes Level hat Vor- und Nachteile: je spezifischer, desto sicherer, aber desto höher der Pflegeaufwand.

Krypto-Einschränkung: Signaturbasierte Regeln funktionieren nur mit RSA (max. 4096 Bit Schlüssellänge). ECC/ECDSA wird nicht unterstützt. Versuchst du, Dateien anhand von ECC-Signaturen zu erlauben, siehst du VerificationError = 23 an den zugehörigen 3089-Events. Solche Dateien lassen sich stattdessen per Hash oder File-Attribute-Regel erlauben – oder über andere Signer-Regeln, wenn die Datei zusätzlich mit RSA signiert ist.

Table 2 – File Rule Levels

Primary- und Fallback-Level: Mit New-CIPolicy gibst du über -Level das primäre File Rule Level an. Binaries, die darüber nicht vertraut werden können, fängt -Fallback ab. Beispiel: Primär PcaCertificate, aber unsignierte Anwendungen sollen ebenfalls erlaubt sein → Hash als Fallback ergänzt die Hash-Werte der unsignierten Binaries.

Versionsnummern erscheinen in der Policy-XML als MinimumFileVersion und MaximumFileVersion. Sind beide gesetzt, gilt bei Allow der Bereich ≥ Min und ≤ Max (bei Deny derselbe Bereich als gesperrt). Nur MinimumFileVersion: Allow erlaubt ≥, Deny sperrt ≤. Nur MaximumFileVersion: Allow erlaubt ≤, Deny sperrt ≥.

Praxisbeispiel für File Rule Levels

Ein Admin betreibt viele Server und will nur Software seiner Hardware-, OS- und AV-Lieferanten laufen lassen. Zusätzlich läuft eine intern entwickelte, unsignierte Anwendung, die selten aktualisiert wird. Vorgehen: Referenz-Server auf Standardhardware bauen, alle bekannten Programme installieren, dann New-CIPolicy mit -Level Publisher (vertraut den Software-Publishern) und -Fallback Hash (erlaubt die interne, unsignierte App) ausführen. Policy im Audit-Modus ausrollen, aus den Audit-Daten nachschärfen, dann in den Enforce-Modus wechseln. Kommen später Updates derselben Publisher, muss die Policy nicht angepasst werden. Wird die interne App aktualisiert, ist ein Policy-Update nötig (neuer Hash).

File Rule Precedence

WDAC löst Regelkonflikte über eine feste Reihenfolge auf:

1. Zuerst alle expliziten Deny-Regeln.
2. Dann alle expliziten Allow-Regeln.
3. Existiert weder Deny noch Allow, prüft WDAC einen Managed-Installer-Claim (falls die Policy es erlaubt).
4. Zuletzt fällt WDAC auf den ISG zurück (falls erlaubt).

Auf Windows-Versionen mit Multi-Policy-Support empfiehlt Microsoft, ALLOW- und DENY-Policies getrennt zu pflegen – das macht das Regelwerk leichter nachvollziehbar.

-SpecificFileNameLevel

Standardmäßig nutzen FileName, FilePublisher und WHQLFilePublisher das OriginalFileName-Attribut aus dem Resource-Header. Über -SpecificFileNameLevel kannst du ein anderes Attribut wählen. Nutzt ein Hersteller z. B. für alle Binaries einer App denselben ProductName, deckst du sie mit einer einzigen Regel statt vieler Einzelregeln ab.

Table 3 – -SpecificFileNameLevel-Optionen

FilePath-Regeln

FilePath-Regeln bieten nicht dieselben Garantien wie Signer-Regeln, weil sie auf veränderbaren Zugriffsrechten basieren. Sie eignen sich für Umgebungen, in denen die meisten Nutzer als Standardbenutzer (nicht als Admin) arbeiten, und für Pfade, die verlässlich nur admin-schreibbar bleiben. Verzeichnisse, in denen Standardnutzer die ACLs ändern können, solltest du meiden.

User-writable-Check: WDAC prüft zur Laufzeit, ob der Pfad nur für Admins schreibbar ist. Dafür gibt es eine feste Liste bekannter Admin-SIDs. Erlaubt der Pfad Schreibrechte für eine SID außerhalb dieser Liste, gilt er als user-schreibbar (auch bei einem Custom-Admin). Diese Laufzeitprüfung lässt sich mit Disabled:Runtime FilePath Rule Protection (Option 18) überschreiben.

Bekannte Admin-SIDs, die WDAC akzeptiert:

S-1-3-0; S-1-5-18; S-1-5-19; S-1-5-20; S-1-5-32-544; S-1-5-32-549; S-1-5-32-550;
S-1-5-32-551; S-1-5-32-577; S-1-5-32-559; S-1-5-32-568;
S-1-15-2-1430448594-2639229838-973813799-439329657-1197984847-4069167804-1277922394;
S-1-15-2-95739096-486727260-2033287795-3853587803-1685597119-444378811-2746676523

Erzeugt New-CIPolicy FilePath-Regeln, entsteht pro gefundener Datei ein voll qualifizierter Pfad. Um stattdessen alle Dateien unter einem Ordner zu erlauben, definierst du mit New-CIPolicyRule und dem Schalter -FilePathRules Regeln mit Wildcards.

Wildcards in FilePath-Regeln

Zusätzlich sind die Makros %OSDRIVE%, %WINDIR% und %SYSTEM32% nutzbar – auch in Kombination mit Wildcards, wenn das Volume variieren kann.

Auf Windows 11 dürfen ein oder mehrere Wildcards überall im Pfad stehen. Auf allen anderen Windows-/Server-Versionen ist nur ein Wildcard pro Pfad erlaubt, und zwar am Anfang oder Ende.

Beispiele:

Ohne Wildcard erlaubt eine FilePath-Regel genau eine Datei (z. B. C:\foo\bar.exe).

Nicht verwechseln: In Configuration Manager gibt es eine Option, Regeln für angegebene Dateien/Ordner zu erstellen. Das sind keine WDAC-FilePath-Regeln – ConfigMgr scannt die Pfade einmalig und baut Regeln für die zum Scan-Zeitpunkt gefundenen Binaries. Spätere Änderungen greifen erst nach erneuter Anwendung der ConfigMgr-Policy.

Hashes

WDAC verwendet den Authenticode/PE-Image-Hash, nicht den bekannteren Flat-File-Hash. Der Authenticode-Hash lässt Checksum, Certificate Table und Attribute Certificate Table aus. Dadurch ändert er sich nicht, wenn Signaturen/Timestamps angepasst oder eine Signatur entfernt wird – weniger Pflege, da keine Policy-Anpassung bei Signaturänderung nötig. Der Hash lässt sich für signierte und unsignierte Dateien berechnen.

• Vier Hash-Regeln pro Datei: Das Cmdlet erzeugt Authenticode SHA1, SHA256 sowie SHA1- und SHA256-Page-Hash. WDAC wählt zur Validierung je nach Signaturart und Nutzungsszenario. Die vier Hashes vorab zu berechnen macht die Policy robust gegen Änderungen an der Signaturart.
• Acht Hash-Regeln bei manchen Dateien: Getrennte Regeln für UMCI und KMCI. Kann das Cmdlet nicht bestimmen, ob eine Datei nur im User- oder Kernel-Mode läuft, entstehen aus Vorsicht Regeln für beide Szenarien. Ist die Nutzung bekannt, lassen sich die überflüssigen Regeln entfernen.
• Flat-File-Hash als Fallback: In seltenen Fällen entspricht ein Dateiformat nicht der Authenticode-Spezifikation (z. B. bei In-Memory-Änderungen zur Laufzeit) – dann nutzt WDAC den Flat-File-Hash. Im 3089-Event sieht man dann, dass der Hash dem Flat-File-Hash aus dem 3076/3077-Block-Event entspricht. Für solche Dateien fügst du Hash-Regeln für den Flat-File-Hash per Wizard oder direkt in der XML hinzu.

WDAC-Basispolicies

Statt eine Policy von null aufzubauen, startest du mit einer Base-Template und ergänzt sie. Die folgenden Basispolicies decken die wichtigsten Härtungsszenarien ab.

Architektur-Hinweis: Die von Microsoft empfohlenen User Mode Block Rules und Kernel Mode Block Rules hält man idealerweise getrennt von der eigenen Base-Policy – sonst müsste bei jedem Update dieser Listen die komplette Base-Policy neu gebaut werden. In der Praxis referenziert man sie über Supplemental Policies (die die Base-Policy erweitern). Wo Supplementals nicht sauber greifen, werden die Regeln stattdessen direkt in die Base-Policy gemergt.

Signed and Reputable Base-Policy

Die „Signed and Reputable"-Vorlage erlaubt Code, der entweder

• von Microsoft/Store signiert ist oder
• vom Intelligent Security Graph (ISG) als vertrauenswürdig eingestuft wird (reputationsbasiert über Defender-SmartScreen-Telemetrie).

Sie ist der pragmatische Mittelweg zwischen „alles erlauben" und einer streng kuratierten Allow-Liste – gut geeignet als Einstieg in produktive WDAC-Deployments.

Produktionsreifes Setting-Profil – siehe die Empfehlungstabelle oben. Kern: UMCI Ein, ISG Ein, Managed Installer Ein (bei Intune/SCCM), Script Enforcement aktiv, Dynamic Code Security Ein, Treat Revoked as Unsigned Ein, HVCI/WHQL/EV Signers Ein (nach Treibertest), im Pilot Audit-Mode Ein und unsignierte Policy erlaubt, in Produktion Audit-Mode Aus und Policy signiert.

Base-Template „Signed and Reputable Mode" im App Control Policy Wizard

Empfohlenes Policy-Rules-Profil für „Signed and Reputable" mit aktivem Audit-Mode

Zwingend zuerst im Audit-Modus pilotieren. Erst nach Auswertung der CodeIntegrity-Event-Logs – 3076/3077 für UMCI, 3023/3033 für KMCI – und sauberem Allowlisting in den Enforce-Modus wechseln. Das spart massiv Tickets von ausgesperrten Usern.

Typische Stolperfallen bei „Signed and Reputable":

1. ISG braucht aktiven Defender + Cloud Protection – auf reinen Drittanbieter-AV-Setups wirkungslos.
2. Die Erstausführung benötigt Internetzugang zur SmartScreen-Reputationsabfrage. Offline-Clients: ISG-Cache vorbefüllen oder zusätzliche Allow-Regeln setzen.
3. Eigenentwickelte oder nischige Branchensoftware hat oft keine Reputation → entweder per Managed Installer ausrollen (empfohlen) oder über eine Supplemental Policy mit Signer-/Hash-Regel ergänzen.
4. Event-Log aktiv beobachten: Microsoft-Windows-CodeIntegrity/Operational und …/AppLocker/MSI and Script.

Dangerous Script Hosts blockieren

Diese Base-Policy blockiert die drei klassischen Skript-Hosts – cscript.exe, wscript.exe und mshta.exe – indem sie die Microsoft-Signatur dieser Binaries explizit verweigert. Ansonsten ist alles erlaubt (Allow *). Es handelt sich also um eine reine Härtungsmaßnahme gegen LOLBin-Missbrauch durch Malware und Phishing-Payloads, die .vbs, .js oder .hta über die signierten MS-Hosts ausführen.

Technische Umsetzung: ein DeniedSigner-Eintrag für die Microsoft Windows Production PCA 2011 in Kombination mit FileAttrib-Regeln auf die drei EXE-Namen. Die original von Microsoft signierten Binaries dieser Hosts werden im User-Mode-Signing-Szenario explizit verweigert, während sonst alles erlaubt bleibt.

Eckdaten der Policy:

• Base-Policy, unsigniert (Unsigned System Integrity Policy)
• Script Enforcement deaktiviert – also kein PowerShell Constrained Language Mode; nur die EXE-Hosts werden blockiert
• Supplemental Policies erlaubt
• Dynamic Code Security aktiviert
• HVCI-Optionen: 2 (Strict)
• Update Policy No Reboot – Updates ohne Neustart möglich

PowerShell selbst wird hier nicht blockiert – dafür braucht es zusätzliche Regeln oder AppLocker / Constrained Language Mode.

RMM-Tools blockieren (Remote Monitoring & Management)

Diese Base-Policy blockiert per FilePath-Deny-Regeln die Installations- und Ausführungspfade einer großen Liste bekannter Remote-Monitoring-&-Management- bzw. Remote-Access-Tools, u. a.:

AnyDesk, TeamViewer, ConnectWise/ScreenConnect, Atera, Kaseya, LogMeIn, Splashtop, RustDesk, Parsec, NetSupport, RealVNC, Chrome Remote Desktop.

RMM-Tools sind ein klassischer Initial-Access- und Persistenz-Vektor bei Ransomware: Angreifer schleusen ein legitimes Remote-Tool ein, um die Fernsteuerung zu behalten. Die Policy unterbindet das – sinnvoll in Umgebungen mit einem klar definierten, freigegebenen Remote-Tool-Stack. Die eingesetzten, offiziell freigegebenen Tools müssen dann per Allow-Regel oder Managed Installer ausgenommen werden.

Strict Kernel Mode

Diese Base-Policy erlaubt im Kernel-Mode ausschließlich Treiber, die direkt mit Microsofts eigenen Windows-, ELAM- oder HAL-EKUs unter den Roots Microsoft Product Root 2010 bzw. Flighting Root 2014 signiert sind – also keine Drittanbieter-Treiber, auch keine WHQL-zertifizierten.

Sie läuft typischerweise zunächst im Audit-Modus (mit aktiviertem HVCI Strict) und ist damit eine extrem restriktive „Microsoft-only Kernel"-Policy zum Schutz vor BYOVD-Angriffen. Wegen ihrer Härte muss sie vor dem Enforcement zwingend getestet werden – viele Umgebungen haben legitime Drittanbieter-Kernel-Treiber (Storage, VPN, Endpoint-Agents), die sonst nicht mehr laden.

Microsoft Recommended User Mode Block Rules

Eine von Microsoft gepflegte Liste von User-Mode-Binaries, die zur Umgehung von App Control / WDAC missbraucht werden können – vor allem LOLBins (Living-off-the-Land-Binaries) wie bash.exe, cdb.exe, kd.exe, csi.exe, MSBuild.exe sowie spezifische verwundbare Versionen legitimer Microsoft-Tools.

Ohne diese Blockliste könnte ein Angreifer eine ansonsten korrekte Allow-Policy aushebeln, indem er Code über ein signiertes, „erlaubtes" Microsoft-Tool ausführt. Die Liste gehört daher in praktisch jede WDAC-Strategie – idealerweise als Supplemental Policy, damit Updates der Liste nicht die Base-Policy zwingen, neu gebaut zu werden.

Microsoft Recommended Driver Blocklist

Eine von Microsoft gepflegte Liste bekannt verwundbarer Kernel-Treiber (Vulnerable Driver Blocklist), die Angreifer im Rahmen von BYOVD-Angriffen (Bring Your Own Vulnerable Driver) einsetzen, um EDR zu deaktivieren und Kernel-Eskalation zu erreichen – ein Standardvektor moderner Ransomware-Operationen.

Anders als „Strict Kernel Mode" (die alles außer Microsoft-Treiber sperrt) ist die Driver Blocklist eine gezielte Deny-Liste bekannter Problem-Treiber – deutlich kompatibler und damit als Basisschutz breit einsetzbar. Auf aktuellen Windows-Versionen ist die Blocklist teilweise bereits standardmäßig aktiv; für maximalen Schutz sollte man die aktuelle Version als eigene Policy pflegen.

WDAC Wizard & Deployment

Der WDAC Wizard erstellt und generiert die für Application Control benötigte XML-Datei komfortabel über eine GUI – ideal, um Policies ohne manuelles XML-Editieren aufzubauen.

Voraussetzung: installiertes .NET Framework.

Download: Microsoft WDAC Wizard (webapp-wdac-wizard.azurewebsites.net) – Direktlink zum MSIX-Paket:

https://webapp-wdac-wizard.azurewebsites.net/packages/WDACWizard_2.4.3.0_x64_8wekyb3d8bbwe.MSIX

Download-Seite des WDAC Policy Wizard

Bedienung Schritt für Schritt:

1. WDAC Wizard starten.

2. Aktion wählen – neue Policy erstellen (Policy Creator), bestehende bearbeiten (Policy Editor) oder mergen (Policy Merger).

   

   Startbildschirm des Wizards mit Policy Creator, Editor und Merger

3. Policy-Type wählen: Single- oder Multiple-Policy. Nur bei Multiple gibt es die Auswahl Base oder Supplemental. Gestartet wird immer mit einer Base-Policy.

   

   Auswahl von Policy-Format und Base- bzw. Supplemental-Policy

4. Base-Template auswählen: Die Templates decken die meisten Einsatzzwecke ab; hier legst du fest, welche „Kategorien" von Software Endanwender ausführen dürfen (z. B. „Signed and Reputable").

5. Policy-Regeln (Rule Options) festlegen: Über Hover erscheint zu jeder Option eine Beschreibung im unteren Bereich des Wizards. Wichtig: Managed Installer anhaken, wenn Softwareverteilung genutzt werden soll!

6. Custom Rules festlegen: Über „Add Custom" ergänzt du eigene Regeln (Publisher, Hash, FilePath usw.) für zusätzliche Programme.

   

   File-Rules-Übersicht mit den Signer-Regeln der Base-Policy

   

   Custom Rule anlegen: Rule Type wählen (Publisher, Path, Hash, Folder Scan …)

   

   Option „Merge with Recommended User Mode / Kernel Block Rules" in den File Rules

7. Abschluss: Die XML-Datei ist erstellt und kann in Intune in eine Regel hochgeladen werden.

   

   Wizard erstellt die Policy und gibt XML- und CIP-Datei aus

Wie funktioniert App Control mit dem ISG? Der ISG ist keine Liste von Apps. Er nutzt dieselbe Sicherheitsintelligenz und Machine-Learning-Analyse wie Defender SmartScreen und Defender Antivirus, um Anwendungen als „bekannt gut", „bekannt schlecht" oder „unbekannt" zu klassifizieren. Diese Cloud-KI basiert auf Billionen Signalen von Windows-Endpunkten und wird alle 24 Stunden neu verarbeitet – die Cloud-Entscheidung kann sich also ändern.

App Control prüft den ISG nur für Binaries, die die Policy weder explizit erlaubt noch verweigert und die nicht über einen Managed Installer installiert wurden. Läuft eine solche Binary, sendet App Control Hash- und Signaturinfos an die Cloud. Meldet der ISG „bekannt gut", darf die Datei laufen – sonst wird sie blockiert. Ist die reputable Datei ein Installer, wird dessen Ruf an alle geschriebenen Dateien weitervererbt; diese erhalten das Kernel-EA $KERNEL.SMARTLOCKER.ORIGINCLAIM. App Control ruft die Reputation periodisch neu ab; mit Enabled:Invalidate EAs on Reboot lassen sich die Caches beim Neustart leeren.

Trusted Installer via Intune hinterlegen

Um Intune als Managed Installer (Trusted Installer) zu hinterlegen, sodass über Intune verteilte Apps automatisch vertraut werden, konfigurierst du die Intune-Verwaltungserweiterung als verwaltetes Installationsprogramm. Über „Hinzufügen" wird die Intune Management Extension auf allen anwendbaren registrierten Geräten im Mandanten als Managed Installer gesetzt; den Rollout-Status (Erfolg/Fehler je Gerät) siehst du im Mandanten.

App Control for Business im Intune Admin Center – Richtlinie erstellen

Reiter „Verwaltetes Installationsprogramm" – über „Hinzufügen" die Intune Management Extension als Managed Installer setzen

Managed Installer „Intune Management Extension" mit Status „Active"

Wichtige Überlegungen zum Managed Installer:

1. Das Festlegen eines Managed Installers ist eine mandantenweite Konfiguration – sie gilt für alle verwalteten Windows-Geräte.
2. Nach dem Aktivieren werden alle über Intune bereitgestellten Apps mit der Managed-Installer-Markierung versehen.
3. Diese Markierung allein hat keine Wirkung darauf, was laufen darf. Sie greift nur in Kombination mit einer WDAC-Policy, die den Managed Installer als Vertrauensquelle nutzt.
4. Es gibt keine rückwirkende Markierung: Apps, die vor der Aktivierung deployt wurden, sind nicht markiert. Für diese brauchst du in der WDAC-Policy explizite Allow-Regeln, sonst laufen sie nicht mehr.
5. Deaktivierst du die Managed-Installer-Policy, werden nachfolgende Apps nicht mehr markiert; bereits markierte Apps bleiben markiert. Ein sauberes Entfernen der Intune-Verwaltungserweiterung als Managed Installer ist separat dokumentiert.

Core WDAC Event Logs – WDAC-Events entstehen an zwei Stellen im Windows Event Viewer:

• Anwendungs- und Dienstprotokolle → Microsoft → Windows → CodeIntegrity → Operational – Events zur Policy-Aktivierung und Kontrolle von Executables, DLLs und Treibern.
• … → Microsoft → Windows → AppLocker → MSI and Script – Events zur Kontrolle von MSI-Installern, Skripten und COM-Objekten.

Die meisten App- und Skript-Fehler bei aktivem WDAC lassen sich über diese beiden Logs diagnostizieren.

Monitoring

Nach dem Rollout geht es darum, den Enforcement-Status zu prüfen und im Blick zu behalten, was tatsächlich blockiert bzw. auditiert wird.

1. Schnellcheck: welche Policies sind aktiv? CITool.exe ist seit Windows 11 22H2 / Server 2022 standardmäßig dabei und das offizielle WDAC-Verwaltungstool.

CITool.exe -lp

Beispiel-Output:

Policy ID:        {D86D4921-9270-457B-B1CA-12FC542CF11D}
Base Policy ID:   {D86D4921-9270-457B-B1CA-12FC542CF11D}
Friendly Name:    WDAC-Signed-and-Reputable-Base-v1
Version:          1.0.0.0
Policy Options:   Enabled:UMCI, Enabled:Audit Mode, ...
Is Effective:     True
Is Enforced:      False   <- entscheidend! False = Audit Mode
Is Authorized:    True
Is On Disk:       True
Is Signed Policy: False

2. Policy-Files im Filesystem. Die aktiven kompilierten Policies (.cip) liegen hier, jeweils nach ihrer PolicyID benannt:

Get-ChildItem "C:\Windows\System32\CodeIntegrity\CiPolicies\Active\"

3. Status der Code-Integrity-Engines – zeigt, ob HVCI und WDAC laufen:

Get-CimInstance -ClassName Win32_DeviceGuard `
  -Namespace root\Microsoft\Windows\DeviceGuard |
  Select-Object CodeIntegrityPolicyEnforcementStatus,
                UsermodeCodeIntegrityPolicyEnforcementStatus,
                VirtualizationBasedSecurityStatus,
                SecurityServicesRunning

4. Event-Logs – was tatsächlich geblockt/auditiert wird:

# Letzte 50 WDAC-Events
Get-WinEvent -LogName "Microsoft-Windows-CodeIntegrity/Operational" -MaxEvents 50

# Nur "wuerde blockiert werden" (Audit) - Event-ID 3076
Get-WinEvent -FilterHashtable @{
    LogName = 'Microsoft-Windows-CodeIntegrity/Operational'
    Id      = 3076
} -MaxEvents 20 | Format-List TimeCreated, Message

# Nur tatsaechlich blockiert (Enforced) - Event-ID 3077
Get-WinEvent -FilterHashtable @{
    LogName = 'Microsoft-Windows-CodeIntegrity/Operational'
    Id      = 3077
}

Event-Details eines 3076-Audit-Events im CodeIntegrity/Operational-Log

Event-ID-Cheat-Sheet:

Für Skripte/MSI werden Events über die AppLocker-Engine im Log Microsoft-Windows-AppLocker/MSI and Script geführt.

5. Intune-seitiger Status. In Intune unter Endpoint Security → App Control for Business → [Policy] → Device status siehst du, ob der Push erfolgreich war. Auf dem Client landen Intune-deployte Policies vor dem Anwenden unter C:\Windows\System32\AppLocker\MDM\.

Empfohlener Quick-Check-Einzeiler als erster Troubleshooting-Schritt – gibt alles Wichtige auf einen Blick:

# WDAC-Statusuebersicht
Write-Host "=== Aktive WDAC Policies ===" -ForegroundColor Cyan
CITool.exe -lp -nameOnly

Write-Host "`n=== Enforcement-Status ===" -ForegroundColor Cyan
$dg = Get-CimInstance -ClassName Win32_DeviceGuard `
    -Namespace root\Microsoft\Windows\DeviceGuard
$status = @{ 0 = 'Off'; 1 = 'Audit'; 2 = 'Enforced' }
[PSCustomObject]@{
    KMCI_Status = $status[[int]$dg.CodeIntegrityPolicyEnforcementStatus]
    UMCI_Status = $status[[int]$dg.UsermodeCodeIntegrityPolicyEnforcementStatus]
    HVCI_Active = ($dg.SecurityServicesRunning -contains 2)
    VBS_Status  = $dg.VirtualizationBasedSecurityStatus
}

Write-Host "`n=== Letzte 5 Block-Events (3076/3077) ===" -ForegroundColor Cyan
Get-WinEvent -FilterHashtable @{
    LogName = 'Microsoft-Windows-CodeIntegrity/Operational'
    Id      = 3076, 3077
} -MaxEvents 5 -ErrorAction SilentlyContinue |
    Select-Object TimeCreated, Id, @{ N = 'File'; E = { $_.Properties[1].Value } }

Regeln aus Audit-Events erstellen

WDAC-Events lassen sich auch zentral über Advanced Hunting in Defender for Endpoint abfragen. Die ActionType-Namen der AppControl*-Events und ihre Event-IDs:

Zusammengefasste Aktionen der letzten 7 Tage (guter Startpunkt im Audit-Modus):

DeviceEvents
| where Timestamp > ago(7d) and ActionType startswith "AppControl"
| summarize Machines = dcount(DeviceName) by ActionType
| order by Machines desc

Beispiel-Ausgabe: AppControl-ActionTypes nach Häufigkeit in Advanced Hunting

Auditierte Blocks der letzten 7 Tage – mit Kontext zum ladenden Prozess:

DeviceEvents
| where ActionType startswith "AppControlExecutableAudited"
| where Timestamp > ago(7d)
| project DeviceId,                                    // Geraet, auf dem der Audit-Block auftrat
          FileName,                                    // Dateiname der auditierten App
          FolderPath,                                  // Systempfad ohne Dateiname
          InitiatingProcessFileName,                   // Elternprozess, der die Datei laedt
          InitiatingProcessVersionInfoCompanyName,     // Firmenname des Elternprozesses
          InitiatingProcessVersionInfoOriginalFileName,// Originaldateiname des Elternprozesses
          InitiatingProcessVersionInfoProductName,     // Produktname des Elternprozesses
          InitiatingProcessSHA256,                     // SHA256 (flat) des Elternprozesses
          Timestamp,                                   // Zeitstempel
          ReportId,                                    // Report-ID (von MDE AH erzeugt)
          InitiatingProcessVersionInfoProductVersion,  // Produktversion des Elternprozesses
          InitiatingProcessVersionInfoFileDescription, // Dateibeschreibung des Elternprozesses
          AdditionalFields                             // enthaelt FQBN signierter Binaries (CN des Leaf, ProductName, OriginalFileName, Version)

Alle Files, die im Enforce-Modus theoretisch blockiert würden (Audit-Policy-Events, letzte 30 Tage) – die wichtigste Abfrage, um vor dem Umschalten auf Enforce keine bösen Überraschungen zu erleben:

DeviceEvents
| where ActionType startswith "AppControlCodeIntegrityPolicyAudited"
| where Timestamp > ago(30d)
| project DeviceId,
          FileName,
          FolderPath,
          InitiatingProcessFileName,
          InitiatingProcessVersionInfoCompanyName,
          InitiatingProcessVersionInfoOriginalFileName,
          InitiatingProcessVersionInfoProductName,
          InitiatingProcessSHA256,
          Timestamp,
          ReportId,
          InitiatingProcessVersionInfoProductVersion,
          InitiatingProcessVersionInfoFileDescription,
          AdditionalFields

Aus Audit-Events eine Policy bauen – der einfachste Weg führt über den WDAC Wizard; für den Skript-Weg per PowerShell gilt:

Voraussetzung: Es muss bereits eine WDAC-Audit-Mode-Policy deployt sein.

Ablauf:

1. Eine von der Policy nicht erlaubte, aber gewünschte Anwendung installieren und starten.
2. In den Logs CodeIntegrity - Operational und AppLocker - MSI and Script prüfen, dass die passenden Events erzeugt wurden.
3. In einer elevated PowerShell die Variablen initialisieren (Beispiel baut auf einer Lamna_FullyManagedClients_Audit.xml auf und erzeugt eine EventsPolicy.xml):

$PolicyName           = "Lamna_FullyManagedClients_Audit"
$LamnaPolicy          = $env:userprofile + "\Desktop\" + $PolicyName + ".xml"
$EventsPolicy         = $env:userprofile + "\Desktop\EventsPolicy.xml"
$EventsPolicyWarnings = $env:userprofile + "\Desktop\EventsPolicyWarnings.txt"

4. Mit New-CIPolicy aus den auditierten Events eine neue Policy generieren – hier mit FilePublisher als Level und Fallbacks; Warnungen landen in einer Textdatei:

New-CIPolicy -FilePath $EventsPolicy -Audit -Level FilePublisher `
  -Fallback SignedVersion,FilePublisher,Hash -UserPEs -MultiplePolicyFormat `
  3> $EventsPolicyWarnings

Das gewählte File Rule Level sorgfältig abwägen: FilePublisher mit Hash-Fallback kann spezifischer sein als gewünscht. Bei Bedarf mit anderen -Level/-Fallback-Optionen erneut ausführen.

5. Die erzeugte EventsPolicy.xml prüfen (auf dem Desktop) und sicherstellen, dass nur gewünschte File-/Signer-Regeln enthalten sind. Überflüssiges per XML-Bearbeitung oder im WDAC Wizard entfernen.
6. EventsPolicyWarnings.txt prüfen: Sie listet Dateien, für die WDAC weder auf dem angegebenen Level noch per Fallback eine Regel bauen konnte.

New-CIPolicy erstellt nur Regeln für Dateien, die noch auf der Platte liegen. Für nicht mehr vorhandene Dateien liefert das Event-Log meist genug Info, um sie manuell in der XML zu ergänzen. Eine bestehende Regel eignet sich als Vorlage; validieren gegen das Schema unter %windir%\schemas\CodeIntegrity\cipolicy.xsd.

7. Die EventsPolicy.xml mit der Base-Policy mergen oder in eine Supplemental Policy umwandeln.
8. Base- bzw. Supplemental-Policy in Binärform (.cip) konvertieren und mit der bevorzugten Methode (z. B. Intune) deployen.

Diese Anleitung ergänzt die MDE-Serie; WDAC ist eine zentrale Hardening-Maßnahme gegen nicht vertrauenswürdige Software.