Was sind Defender ASR-Regeln per GPO?
Defender ASR-Regeln per GPO ermöglichen Administratoren, verhaltensbasierte Schutzmaßnahmen über Gruppenrichtlinien an Windows-Geräte zu verteilen. Regeln zur Verringerung der Angriffsfläche (Attack Surface Reduction, ASR) zielen auf Aktivitäten wie Office-Anwendungen, die untergeordnete Prozesse erzeugen, oder Skripte, die heruntergeladene ausführbare Dateien starten. Entscheidend ist, welche Regel-GUIDs, Modi und Ausschlüsse das Zielgerät tatsächlich besitzt, statt nur zu prüfen, ob eine ASR-Richtlinie existiert. Konfigurationsanleitung von Microsoft
Eine Richtlinie kann einen vorgesehenen Schutz beschreiben, ohne nachzuweisen, dass jeder Computer ihn erhält. Der Audit-Modus kann relevante Aktivitäten protokollieren, ohne sie zu blockieren; Ausschlüsse können verändern, was eine Regel auswertet. Prüfen Sie die Bereitstellungsquelle und die Endpunktkonfiguration gemeinsam, bevor Sie die Abdeckung melden.
Diese Anleitung verwendet Microsoft-Learn-Seiten, die am 3. Oktober 2026 geprüft wurden, und die untersuchte Implementierung von etc-collector. Die PowerShell-Befehle sind auf der Dokumentation beruhende Beispiele für einen autorisierten Windows-Administrator; für diesen Artikel wurden sie nicht in einer Windows-Umgebung ausgeführt. Es werden weder eine Endpunktabdeckung noch die Verbreitung von Angriffen oder eine erfolgreiche Behebung behauptet.
Funktionsweise: Matrix aus Regeln, Modi und Ausschlüssen
Die ASR-Konfiguration ist eine Liste von Regeln mit individuellen Aktionen. Bearbeiten Sie in der Gruppenrichtlinienverwaltung die vorgesehene GPO unter Computerkonfiguration → Administrative Vorlagen → Windows-Komponenten → Microsoft Defender Antivirus → Microsoft Defender Exploit Guard → Attack Surface Reduction. Öffnen Sie Configure Attack Surface Reduction rules, wählen Sie Enabled und tragen Sie über Show... jede Regel-GUID als Wertnamen und ihren Modus als Wert ein. Ältere Vorlagen können im Pfad Windows Defender Antivirus verwenden. GPO-Verfahren von Microsoft
Die von Learn dokumentierten numerischen Aktionen sind:
| Wert | Modus | Bedeutung für die Prüfung |
|---|---|---|
0 | Off (Aus) | Die Regel ist deaktiviert. |
1 | Block (Blockieren) | Die Regel ist so konfiguriert, dass sie das betreffende Verhalten blockiert. |
2 | Audit (Überwachen) | Die Regel zeichnet Aktivitäten zur Auswertung auf, ohne Benutzer zu blockieren. |
5 | Not configured (Nicht konfiguriert) | Dieser Eintrag legt keine Entscheidung zur Durchsetzung fest. |
6 | Warn (Warnen) | Nur bei Regeln verwenden, die diesen Modus unterstützen; Benutzerübersteuerungen prüfen. |
Die Werte stammen von der Seite zur ASR-Konfiguration. Verfügbarkeit der Modi, Abhängigkeiten und Betriebssystemunterstützung müssen weiterhin für jede Regel in der Referenz der ASR-Regeln geprüft werden.
Erstellen Sie eine Matrix mit einer Zeile pro vorgesehener Regel und Zielpopulation. Die folgenden Zeilen sind Prüfbeispiele, weder ein empfohlener vollständiger Regelsatz noch Messungen aus einer Umgebung:
| Regel | GUID laut Learn | Zu dokumentierender vorgesehener Modus | Prüfung der Ausschlüsse |
|---|---|---|---|
| Alle Office-Anwendungen daran hindern, untergeordnete Prozesse zu erzeugen | d4f940ab-401b-4efc-aadc-ad5f3c50688a | Pilotaktion und anschließend die genehmigte Durchsetzungsaktion dokumentieren | Legitime Office-Abläufe ermitteln, die einen anderen Prozess starten; jede genehmigte Ausnahme dokumentieren. |
| Diebstahl von Anmeldeinformationen aus dem Windows Local Security Authority Subsystem blockieren | 9e6c4e1f-7d60-472f-ba1a-a39ef669e4b2 | Gewählte Aktion dokumentieren; Warn wird nicht unterstützt | Anwendbarkeit zusammen mit vorhandenem LSA-Schutz und Credential Guard prüfen. |
Microsoft dokumentiert für die Office-Regel eine Bedingung zum Installationsort: Office muss unter %ProgramFiles% oder %ProgramFiles(x86)% installiert sein. Microsoft erklärt außerdem, dass die LSASS-Regel bei aktiviertem LSA-Schutz nicht erforderlich ist und keinen zusätzlichen Schutz bietet, und empfiehlt diesen Schutz zusammen mit Credential Guard. Behandeln Sie nicht jede verfügbare Regel als uneingeschränkte Anforderung. Regelspezifische Einzelheiten
Unsere Anleitung zu Credential Guard nach einem Upgrade erläutert, wie sich die VBS-basierte Isolation von Anmeldeinformationen und eine geerbte Deaktivierung prüfen lassen. Diese Nachweise belegen nicht die Konfiguration des umfassenderen ASR-Verhaltensregelsatzes. Halten Sie die Anwendbarkeit der Schutzmaßnahmen und ihre Messungen getrennt.
Ermitteln, welche Verwaltungsquelle Vorrang hat
Ein GPO-Eintrag und ein Intune-Profil können für dieselbe Regel miteinander in Konflikt stehen. Die aktuelle Learn-Konfigurationsseite dokumentiert, dass richtlinienbasierte Einstellungen beim Start Vorrang vor lokalen Set-MpPreference-Einstellungen haben. Laut dieser Seite haben Gruppenrichtlinien standardmäßig Vorrang vor MDM; MDMWinsOverGP=1 bevorzugt MDM. Sie rät davon ab, dieselben ASR-Regeln über beide Quellen zu konfigurieren. Die separate Defender-Anleitung zur Problembehandlung von Microsoft weist darauf hin, dass dieser Schalter unter Windows 10 nicht für ASR-Regeln gilt. Die Seiten unterscheiden sich an dieser Grenze: Prüfen Sie das Zielbetriebssystem und das beobachtete Richtlinienergebnis, statt anzunehmen, dass das Flag jeden Konflikt löst.
Es gibt eine weitere ausdrückliche Grenze: controlled configuration setzt Einstellungen von Intune oder der Sicherheitseinstellungsverwaltung von Defender for Endpoint durch und ignoriert widersprechende Einstellungen aus Gruppenrichtlinien, Configuration Manager und lokaler Konfiguration. Prüfen Sie, ob dieser Mechanismus greift, bevor Sie der GPO die Zuständigkeit zuweisen. Umgang von Microsoft mit Richtlinienkonflikten
Dokumentieren Sie die vorgesehene Verwaltungsquelle, die Gerätepopulation, widersprechende Profile und den Nachweis für die wirksame Konfiguration. Eine vorübergehende lokale PowerShell-Änderung kann verschwinden, sobald die verwaltete Richtlinie greift. Als alleiniger Nachweis, dass die verwaltete Bereitstellung korrigiert wurde, ist sie daher ungeeignet.
Erkennung: GPO-Vorgaben mit der Endpunktkonfiguration vergleichen
Schritt 1: Die vorgesehene Richtlinie sichern
Lesen Sie die konfigurierte GUID/Aktionsliste und die Ausschlüsse aus der tatsächlichen GPO. Prüfen Sie deren dekodierte registry.pol-Daten für den ASR-Zweig von Windows Defender Exploit Guard und bewahren Sie die GPO-Identität sowie den Erfassungszeitpunkt zusammen mit den Nachweisen auf. Eine binäre Richtliniendatei muss mit einem richtliniengerechten Verfahren dekodiert werden; ihr Dateiname allein verrät ihre Einstellungen nicht.
Halten Sie die Liste einzelner Regeln vom aggregierten DWORD exploitguard_asr_rules getrennt, das der unten beschriebene Collector-Parser verwendet. Eine aktivierte aggregierte Einstellung ist kein Inventar von GUIDs und Aktionen.
Unsere Anleitung zu vier Sicherheitsprüfungen für Active-Directory-GPOs wendet dieselbe Prüfmethode auf LLMNR, WSUS, LSA-Schutz und UNC-Pfade an: Richtlinienvorgaben, Zielumfang und Clientnachweise vergleichen. Diese vier Kontrollen belegen keine ASR-Abdeckung; ihre Prüfdisziplin ist hier hilfreich.
Schritt 2: Einstellungen des Zielgeräts auslesen
Rufen Sie auf jedem zu bewertenden Zielgerät die Defender-Einstellungen ab. Die Get-MpPreference-Referenz dokumentiert das Cmdlet und seine standardmäßig lokale Ausführung. Die ASR-Konfigurationsseite dokumentiert die Eigenschaften für Regel-IDs und Aktionen.
Führen Sie die folgenden Befehle einzeln in der administrativen PowerShell-Sitzung des Zielgeräts aus:
$p = Get-MpPreference
$p.AttackSurfaceReductionRules_Ids
$p.AttackSurfaceReductionRules_Actions
Ordnen Sie die Einträge anhand ihrer Arrayposition zu: Die Aktion an einem Index gehört zur Regel-ID am selben Index. Bewahren Sie die ursprüngliche Ausgabe auf. Wenn eine Liste fehlt, die Längen voneinander abweichen oder die Erfassung fehlschlägt, dokumentieren Sie das Ergebnis als ungeklärt, statt Einträge stillschweigend wegzulassen oder Konformität zu erklären.
Bei zwei übereinstimmend ausgerichteten, nicht leeren Arrays zeigt dieses Beispiel die Zuordnung:
for ($i = 0; $i -lt $p.AttackSurfaceReductionRules_Ids.Count; $i++) {
[pscustomobject]@{
Id = $p.AttackSurfaceReductionRules_Ids[$i]
Action = $p.AttackSurfaceReductionRules_Actions[$i]
}
}
Prüfen Sie die globalen ASR-Ausschlüsse mit dem von Microsoft dokumentierten Lesebefehl:
(Get-MpPreference).AttackSurfaceReductionOnlyExclusions
Prüfen Sie außerdem regelspezifische Ausschlüsse in der maßgeblichen Verwaltungsrichtlinie. Die globale Liste allein ist keine vollständige Prüfung der Ausnahmen, wenn regelspezifische Ausschlüsse konfiguriert sind. Ausschlusskonfiguration von Microsoft
Vergleichen Sie jede erwartete GUID und jeden erwarteten Modus mit der Endpunktausgabe. Untersuchen Sie fehlende Regeln, unerwartete Aktionen und unerwartete Ausschlüsse. Erfassen Sie Host, Beobachtungszeitpunkt und Verwaltungsquelle; wiederholen Sie die Prüfung nach der Richtlinienanwendung, um eine vorübergehende lokale Einstellung vom verwalteten Ergebnis zu unterscheiden. Diese Einstellungen belegen die Gerätekonfiguration, während Aktivitätstelemetrie nachweist, dass eine Regel ausgelöst wurde.
Schritt 3: ASR-Ereignisse prüfen
Navigieren Sie in der Ereignisanzeige zu Anwendungs- und Dienstprotokolle → Microsoft → Windows → Windows Defender → Operational. Microsoft führt auf seiner Seite zur Windows-Ereignisanzeige die folgenden ASR-Regelereignisse auf:
| Ereignis-ID | Dokumentiertes Signal | Grenze der Interpretation |
|---|---|---|
1121 | Regel löst im Block-Modus aus | Regel und Aktivität im Ereignis prüfen; dies ist kein Nachweis für jede konfigurierte Regel. |
1122 | Regel löst im Audit-Modus aus | Das Ereignis protokolliert ausgewertete Aktivität, keinen blockierten Vorgang. |
1129 | Benutzer übersteuert eine Blockierung im Warn-Modus | Übersteuerung und betroffenen Arbeitsablauf prüfen. |
5007 | Einstellungsänderung | Geänderte Einstellung prüfen; die ID allein kennzeichnet keine ASR-Änderung. |
Gleichen Sie Regelkennung, Gerät, Zeit und Aktivität mit der Konfigurationsmatrix ab. Microsoft dokumentiert auch Windows Event Forwarding für eine zentralisierte Erfassung. Die Anleitung zum Testen der Bereitstellung unterscheidet die lokale Ereignisanzeige von Berichtsfunktionen, die vom Defender-Produkt und -Plan abhängen.
Behebung: Genehmigte Regeln pilotieren, prüfen und durchsetzen (Remediation)
Schritt 1: Einen repräsentativen Piloten festlegen
Wählen Sie eine kontrollierte Gerätepopulation und die Verantwortlichen für Anwendungen aus. Prüfen Sie Unterstützung und Abhängigkeiten der gewählten Regeln, bestimmen Sie die Verwaltungsquelle und dokumentieren Sie die anfänglichen Endpunkteinstellungen. Berücksichtigen Sie Geschäftsabläufe, die die Regeln voraussichtlich auslösen, statt ein untätiges Gerät als Kompatibilitätstest zu behandeln.
Microsofts Bereitstellungsleitfaden gliedert die Arbeit in Planung, Tests, Aktivierung und laufende Überwachung. Laut Microsoft können Regeln für den Standardschutz üblicherweise ohne Tests direkt in Block oder Warn beginnen, während andere Regeln zunächst in Audit bewertet werden sollten. Ein Audit-Pilot ist hier eine bewusste Entscheidung zur Auswertung, keine Behauptung, Microsoft verlange für jede Regel dieselbe Abfolge.
Schritt 2: Audit über die zuständige Richtlinie konfigurieren
Aktivieren Sie für den GPO-verwalteten Piloten Configure Attack Surface Reduction rules und tragen Sie in Show... die ausgewählten GUIDs und die Aktion 2 ein. Verwenden Sie die dokumentierten Werte ohne Anführungszeichen, zusätzliche Zeichen oder führende beziehungsweise nachgestellte Leerzeichen. Bestätigen Sie, dass die vorgesehenen Pilotcomputer diese GPO erhalten, und wiederholen Sie anschließend die Erfassung der Endpunkteinstellungen.
Der Wertname der Office-Regel für untergeordnete Prozesse lautet beispielsweise d4f940ab-401b-4efc-aadc-ad5f3c50688a; ihr Audit-Wert ist 2. Dies veranschaulicht Microsofts GUID/Aktionszuordnung, keine entdeckte Konfiguration. GPO-Regelkonfiguration
Schritt 3: Ereignisse prüfen und Anwendungsausnahmen dokumentieren
Ermitteln Sie anhand von Audit-Aktivitäten legitime Arbeitsabläufe, die durch die Durchsetzung unterbrochen werden könnten. Prüfen Sie den tatsächlichen Prozess- und Dateikontext mit dem Anwendungsverantwortlichen, bevor Sie einen Ausschluss genehmigen. Dokumentieren Sie betroffene Regel, genaue Ausnahme, Grund, Verantwortlichen und Prüfentscheidung.
Gruppenrichtlinien bieten sowohl globale als auch regelspezifische Ausschlüsse. Learn beschreibt im Verfahren für globale GPO-Ausschlüsse den Ausschluss bestimmter Dateien als vorzugswürdig gegenüber dem Ausschluss eines ganzen Ordners. Regelspezifische Ausschlüsse benötigen geeignete administrative Vorlagen; die aktuelle Seite nennt Vorlagen ab 24H2, wenn diese Einstellung in GPMC fehlt. Prüfen Sie die verfügbare Einstellung, bevor Sie die Bereitstellung darauf aufbauen. GPO-Ausschlüsse von Microsoft
Schritt 4: Zu Block oder unterstütztem Warn wechseln und erneut prüfen
Ändern Sie die genehmigten Regelaktionen in der zuständigen Richtlinie auf Block 1 oder, sofern unterstützt und angemessen, auf Warn 6. Die LSASS-Regel gegen den Diebstahl von Anmeldeinformationen unterstützt Warn nicht. Erweitern Sie die Bereitstellung nach der Prüfung von Anwendungsverhalten und Endpunktkonfiguration über Bereitstellungsringe. Bereitstellungsleitfaden und Regelreferenz
Wiederholen Sie den GUID/Aktionsvergleich und prüfen Sie Block-Ereignisse oder Warn-Übersteuerungen. Eine abgeschlossene GPO-Bearbeitung ist nicht das Abnahmekriterium. Schließen Sie die Bereitstellungsentscheidung für eine Population erst ab, wenn die vorgesehene Konfiguration auf ihren bewerteten Geräten beobachtet wurde, relevante Arbeitsabläufe geprüft wurden und verbleibende Ausnahmen oder unbekannte Geräte ausdrücklich dokumentiert sind.
Ersetzen Sie eine verwaltete Regelliste nicht durch einen bequemen lokalen Befehl. Microsoft warnt, dass Set-MpPreference die vorhandenen Regeln und Aktionen überschreibt, die über dieses Cmdlet übergeben werden, und dass verwaltete Einstellungen beim Start widersprechende lokale Änderungen überschreiben. Lösen Sie den Quellenkonflikt und erhalten Sie nicht betroffene Konfiguration. Verhalten der PowerShell-Konfiguration
Wie EtcSec dies erkennt
EtcSecs etc-collector enthält DEFENDER_ASR_NOT_CONFIGURED, eine GPO-Konfigurationsprüfung mit mittlerem Schweregrad. Die untersuchte Implementierung defender-asr.go ruft FindRegistrySettingInt für DefenderASREnabled auf. Ein fehlender Wert oder ein Wert ungleich 1 ergibt Count 1; bei einem Wert von 1 bleibt Count 0.
Der Helper priorisiert einen Nicht-nil-Wert aus Default Domain Controllers Policy, dann aus Default Domain Policy und anschließend aus einer anderen verfügbaren GPO. Dies ist die Suchreihenfolge des Collectors, nicht die Windows-Richtlinienpräzedenz für einen einzelnen Endpunkt. Er berechnet nicht die wirksamen Verknüpfungen, Filter, Vererbung oder MDM-Konflikte jedes Computers.
Der untersuchte registrypol_parser.go befüllt das Feld ausschließlich aus einem DWORD namens exploitguard_asr_rules in einem Schlüssel, der Windows Defender und ASR enthält. Er befüllt für diese Prüfung nicht das vollständige GUID/Aktionsinventar. Der gegen 1 geprüfte aggregierte Wert darf nicht als Block-Aktion jeder einzelnen Regel interpretiert werden.
Nutzen Sie dieses Signal, um eine gezielte Konfigurationsuntersuchung einzuleiten. Fügen Sie die vorgesehene GPO-Liste, Endpunkteinstellungen und relevante ASR-Ereignisse dem Behebungsnachweis bei. Halten Sie nicht verfügbare Messungen bis zu ihrer Erfassung als ungeklärt fest; eine Konfigurationsprüfung auf Domänenebene kann Endpunktnachweise nicht ersetzen.
Entdecken Sie die Identity-Security-Seiten zu diesem Thema
