Microsoft Defender for Endpoint: Attack Surface Reduction

Microsoft Defender Antivirus ist die Next-Generation-Schutzkomponente von Defender for Endpoint und kombiniert Machine Learning, Big-Data-Analysen, Threat Research und die Microsoft-Cloud zu einem mehrschichtigen Echtzeitschutz. Über die reinen AV-Basiseinstellungen hinaus bringt MDE aber eine ganze Reihe zusätzlicher Schutzmechanismen mit, deren gemeinsames Ziel es ist, die Angriffsfläche (Attack Surface) eines Geräts zu verkleinern.

Grob lassen sich diese Funktionen in zwei Kategorien einteilen:

• Attack Surface Reduction (ASR) – eine Sammlung von Kontrollen, die typische Malware- und Exploit-Techniken blockieren: ASR-Regeln, Controlled Folder Access, Device Control, Exploit Protection, Network Protection, Web Protection, Ransomware-Schutz, Application Control und hardwarebasierte Isolation.
• Zusätzlicher Defender-Schutz – Funktionen, die das Sicherheitsniveau weiter anheben: Credential Guard, SmartScreen und die Windows Defender Firewall.

Dieser Teil der Serie geht die praxisrelevanten Bausteine durch – von den ASR-Regeln über Firewall, Web Protection und SmartScreen bis hin zu Controlled Folder Access, Credential Guard und Device Control.

Attack Surface Reduction (ASR-Regeln)

ASR fasst eine Reihe von Kontrollen zusammen, die gängige Malware- und Exploit-Techniken einschränken. Die ASR-Regeln sind der bekannteste Teil davon: Sie wirken wie eine Abschirmung gegen typische Angriffsvektoren und blockieren Aktivitäten, die häufig mit schädlichen Aktionen einhergehen – idealerweise schon beim ersten Schritt der Angriffskette. Beispiele für solche blockierten Aktivitäten:

• Office-Anwendungen daran hindern, Unterprozesse (Child Processes) zu erzeugen.
• Office-Anwendungen daran hindern, Code in andere Prozesse zu injizieren.
• JavaScript- oder VBScript-Dateien daran hindern, heruntergeladene ausführbare Dateien zu starten.
• Das Auslesen von Anmeldeinformationen aus dem LSASS-Prozess (lsass.exe) blockieren.

Voraussetzungen

ASR-Regeln greifen nur, wenn Defender Antivirus im aktiven Modus läuft – nicht im passiven Modus. Einige Regeln setzen zusätzlich den Cloud-basierten Schutz voraus, der ohnehin grundsätzlich empfohlen wird. Weitere Voraussetzungen:

• Windows 10 Pro, Enterprise oder Education in Version 1709 oder neuer.
• Windows Server 2012 R2 / 2016 mit dem MDE Unified Agent.

ASR-Zustände

Über die Verwaltungsmechanismen (Intune, Gruppenrichtlinien, PowerShell) lassen sich ASR-Regeln in verschiedene Zustände versetzen:

• Nicht konfiguriert: Standardzustand, keine Wirkung.
• Block: Die Aktion wird aktiv blockiert.
• Audit (Überwachen): Keine Blockade, aber die entsprechenden Ereignisse werden protokolliert.
• Warn: Die Regel greift, der Nutzer kann den Block aber bewusst umgehen.

Im Audit-Modus wird also nur protokolliert, es findet keine Blockierung statt. Genau das macht ihn zum idealen Einstiegspunkt: Man aktiviert die Regeln zunächst durchgängig im Audit-Modus, wertet die erzeugten Ereignisse aus (über Berichte oder Advanced Hunting) und wechselt erst danach schrittweise in den Block-Modus.

Standard-ASR-Schutz

Microsoft hat einige Regeln als Standard Protection definiert, die grundsätzlich immer aktiviert bleiben sollten:

• Auslesen von Anmeldeinformationen aus LSASS (lsass.exe) blockieren.
• Missbrauch ausgenutzter, verwundbarer signierter Treiber blockieren.
• Persistenz über WMI-Ereignisabonnements blockieren.

Die LSASS-Regel erzeugt in der Praxis oft viele Benachrichtigungen. Erfahrungsgemäß sind darunter viele Fehlalarme – eine Whitelist ist meist trotzdem nicht nötig. Die Standard-ASR-Regeln sollten in jedem Fall dauerhaft aktiv sein.

Bereitstellungsplan

Ein sicherer Rollout folgt einem festen Muster, das jede Aktivierung erst beobachtet, bevor sie scharf geschaltet wird:

1. ASR-Regeln für eine erste Testgruppe im Audit-Modus aktivieren.
2. Audit-Ereignisse im Defender-Portal auswerten (Berichte, Advanced Hunting).
3. ASR-Regeln im Audit-Modus für alle Geräte aktivieren.
4. Audit-Ereignisse erneut prüfen.
5. Bei Bedarf Ausnahmen (Exclusions) anlegen – so wenige wie möglich.
6. ASR-Regeln für die erste Gerätegruppe auf Block setzen.
7. ASR-Berichte und Meldungen im Portal überprüfen.
8. Weitere Ausnahmen nur hinzufügen, wenn es wirklich nötig ist.
9. Den Geltungsbereich schrittweise erweitern und die Auswirkungen überwachen.

Jede Ausnahme ist eine potenzielle Sicherheitslücke. Ausnahmen sollten nur bei echten Problemen genutzt werden. Oft ist es besser zu verstehen, warum ein Nutzer oder Prozess eine blockierte Aktion auslöst, und eine Alternative zu finden, statt die Regel zu lockern.

Reporting und Advanced Hunting

Im Defender-Portal findet man unter Berichte → Attack Surface Reduction Rules eine Übersicht über Audit- und Block-Ereignisse je Regel. Standardmäßig ist der Filter Standard Protection aktiv; um alle Regeln zu sehen, stellt man ihn auf Alle.

Der Attack-Surface-Reduction-Bericht im Defender-Portal.

Audit- und Block-Erkennungen je ASR-Regel über einen Zeitraum – die Legende zeigt, ob nur überwacht oder aktiv blockiert wurde.

Für detaillierte Auswertungen eignet sich Advanced Hunting. Diese Abfrage zeigt, welche ASR-Regeln wie oft ausgelöst wurden und welche Prozesse beteiligt waren:

DeviceEvents
| where ActionType startswith "Asr"
| summarize ASRCount = count() by ActionType, InitiatingProcessCommandLine
| sort by ActionType asc, ASRCount desc

Eine kompakte Zusammenfassung pro Regel:

DeviceEvents
| where ActionType startswith "Asr"
| summarize NumberOfEvents = count() by ActionType
| sort by NumberOfEvents desc

Konfiguration mit Intune

In Intune verwendet man immer das aktuelle Endpoint-Security-Profil. Unter Endpoint Security → Attack Surface Reduction legt man ein neues Profil vom Typ Attack Surface Reduction Rules an, wählt die Plattform (z. B. Windows 10 und höher) und stellt danach jede Regel einzeln ein (Off, Audit, Block oder Warn).

Unter Endpoint Security → Attack Surface Reduction ein neues Profil vom Typ „Attack Surface Reduction Rules" erstellen.

Jede ASR-Regel lässt sich einzeln auf Off, Audit, Block oder Warn setzen.

Die Regel „Block Webshell creation for Servers" gilt ausschließlich für Exchange-Server. Auf allgemeinen Endgeräten sollte sie nicht aktiviert werden, da sie dort andere ASR-Regeln stören kann.

Konfiguration mit Gruppenrichtlinien (GPO)

Voraussetzung sind aktuelle Defender-ADMX-Vorlagen. Die Einstellungen liegen im Gruppenrichtlinien-Editor unter:

Computer Configuration → Administrative Templates → Windows Components →
  Microsoft Defender Antivirus → Microsoft Defender Exploit Guard →
    Attack surface reduction

In der GPO werden die Regeln über ihre GUID gesteuert. Die möglichen Werte:

• 0 – Deaktivieren (Regel aus)
• 1 – Block (Regel aktiv, blockiert)
• 2 – Audit (Überwachungsmodus)
• 6 – Warn (Regel aktiv, Nutzer kann den Block umgehen)

Die wichtigsten Regeln mit ihren GUIDs:

Konfiguration mit PowerShell

Über Set-MpPreference (überschreibt) oder Add-MpPreference (ergänzt) lassen sich Regeln direkt setzen:

# Enabled (Block)
Set-MpPreference -AttackSurfaceReductionRules_Ids <rule ID> -AttackSurfaceReductionRules_Actions Enabled

# Audit
Add-MpPreference -AttackSurfaceReductionRules_Ids <rule ID> -AttackSurfaceReductionRules_Actions AuditMode

# Warn
Add-MpPreference -AttackSurfaceReductionRules_Ids <rule ID> -AttackSurfaceReductionRules_Actions Warn

Konkretes Beispiel für die Adobe-Reader-Regel:

Set-MpPreference -AttackSurfaceReductionRules_Ids 7674ba52-37eb-4a4f-a9a1-f0f9a1619a2c -AttackSurfaceReductionRules_Actions Enabled

Windows-Firewall

Eine häufige Frage lautet: Braucht man für MDE überhaupt eigene Windows-Firewall-Richtlinien? Die klare Antwort ist ja. Die Bedeutung der Windows Defender Firewall im Zusammenspiel mit Defender for Endpoint wird in vielen Organisationen unterschätzt.

MDE bietet mehrere Ebenen von Netzwerk-Monitoring auf Basis des Netzwerkverkehrs – inklusive nativer Netzwerkerkennung und Events in der Tabelle DeviceNetworkEvents. Damit diese Funktionen voll greifen, muss die Windows-Firewall auf allen Profilen (Domäne, Privat, Öffentlich) aktiviert sein und es müssen zusätzliche Auditing-Einstellungen gesetzt werden.

Auditing-Unterkategorien

Zwei Unterkategorien sind für das Firewall-Reporting entscheidend:

• Filtering Platform Packet Drop – protokolliert, wenn Pakete aufgrund von Firewall-Regeln verworfen werden.
• Filtering Platform Connection – protokolliert Verbindungsversuche bzw. abgebrochene Verbindungen.

Ohne aktiviertes Auditing ist der Firewall-Bericht nicht funktionsfähig. Zusätzliche Ereigniserfassung erzeugt aber auch deutlich mehr Daten – sowohl erfolgreiche als auch fehlgeschlagene Verbindungsversuche. Ist ein SIEM (z. B. Microsoft Sentinel) angebunden, sollte man das Datenvolumen und die daraus resultierenden Kosten im Blick behalten und Aufwand und Nutzen abwägen.

Empfehlung

Firewall für alle Zonen aktivieren, die Audit-Unterkategorien für Packet Drop und Connection einschalten (in der Regel reicht failure), und idealerweise die TVM-Empfehlungen für die Firewall anwenden. Wichtig: die lokale Admin-Zusammenführung (local admin merge) deaktivieren – lokale Regeln sollten also sorgfältig bewertet und nur bewusst zugelassen werden.

Konfiguration mit Intune

Unter Endpoint Security → Firewall erstellt man ein neues Firewall-Profil mit folgender Grundkonfiguration:

• Firewall für alle Zonen (Domäne, privates Netzwerk, öffentliches Netzwerk) aktivieren.
• Audit für die Failure-Ereignisse der Unterkategorien Packet Drop und Connection aktivieren.
• Weitere empfohlene Einstellungen aus den Microsoft Security Baselines übernehmen.

Die Advanced Audit Policy lässt sich alternativ direkt in Intune konfigurieren.

Über die Advanced Audit Policy in Intune lassen sich die benötigten Auditing-Unterkategorien setzen.

Konfiguration mit PowerShell

# Firewall-Profile aktivieren (Domäne, privat, öffentlich)
Set-NetFirewallProfile -Profile Domain,Public,Private -Enabled True

# Audit für Paket-Drops aktivieren
auditpol /set /subcategory:"Filtering Platform Packet Drop" /failure:enable

# Audit für Verbindungsversuche aktivieren
auditpol /set /subcategory:"Filtering Platform Connection" /failure:enable

Reporting

Nach Aktivierung von Firewall und Audit liefert das Defender-Portal unter Berichte → Firewall detaillierte Netzwerkdaten – etwa blockierte ausgehende Verbindungen, häufigste blockierte Ports und die verantwortlichen Prozesse. Pro Ereignis stehen typischerweise zur Verfügung:

• Remote-IP-Adresse und Remote-Port
• Lokale IP-Adresse und lokaler Port
• Computername
• Prozessname (für ein- und ausgehende Verbindungen)

Bei aktivem Auditing zeichnet MDE Remote-/lokale IP und Ports, Computer- und Prozessname der Verbindung auf.

Diese Datenpunkte ermöglichen tiefe Einblicke in verdächtige Netzwerkaktivitäten und helfen, blockierte Verbindungen zu analysieren und Angriffe zu erkennen.

Webschutz (Network & Web Protection)

Der Webschutz in Defender for Endpoint umfasst drei Bausteine: Web Threat Protection, Web Content Filtering und Custom Indicators. Er baut technisch auf Network Protection und SmartScreen auf.

• Custom Indicators blockieren gezielt bestimmte URLs oder Web-IoCs.
• Web Content Filtering erlaubt es, ganze Kategorien von Webseiten zu überwachen oder zu blockieren.

Unter security.microsoft.com → Einstellungen → Endpoints → Web Content Filtering legt man eine neue Richtlinie an und wählt die zu blockierenden Kategorien aus. Wählt man keine Kategorie, entsteht eine reine Audit-Only-Richtlinie, die lediglich protokolliert. Typische Verdachtskategorien sind neu registrierte Domains oder geparkte Domains, hinter denen häufig Phishing-Seiten stecken.

Unter Einstellungen → Endpoints → Web Content Filtering eine neue Richtlinie erstellen.

Bei der Kategorienauswahl gehören neu registrierte und geparkte Domains zu den typischen Verdachtskategorien.

Webschutz zunächst im Audit-Modus betreiben, um Einblick zu gewinnen. Vor allem aber: Network Protection im Block-Modus aktivieren – erst dann funktionieren Web Threat Protection und SmartScreen vollständig.

Das Reporting der Web Protection findet sich im Defender-Portal unter Berichte.

Network Protection (Command-and-Control-Blockierung)

Network Protection dehnt die Angriffsflächenreduzierung auf die Netzwerkebene aus, etwa zur Erkennung und Blockierung von Command-and-Control-Kommunikation (C2). Ist Network Protection aktiv, kann MDE C2-Traffic auf Prozessebene erkennen und unterbinden.

So sieht ein durch Network Protection blockierter Command-and-Control-Zugriff im Portal aus.

Nach Aktivierung lässt sich der Block testen: Der folgende Aufruf bricht mit einem SSL/TLS-Fehler ab, wenn die Test-URL blockiert wird:

Invoke-WebRequest -URI https://commandcontrol.smartscreentestratings.com

Network Protection sollte im Block-Modus laufen. Web Threat- und Network Protection werden nur wirksam, wenn Network Protection generell aktiv ist. Werden legitime Seiten fälschlich blockiert, legt man dafür Custom Indicators vom Typ „Allow" an.

Hunting für Netzwerkschutz und SmartScreen

Blockierte C2-Verbindungen aus einer eigenen (Custom-)Policy:

DeviceEvents
| where ActionType == "ExploitGuardNetworkProtectionBlocked"
| extend ParsedFields = parse_json(AdditionalFields)
| project DeviceName, ActionType, Timestamp, RemoteUrl, InitiatingProcessFileName,
          ResponseCategory = tostring(ParsedFields.ResponseCategory)
| where ResponseCategory == "CustomPolicy"

SmartScreen-Warnungen aus einer Custom-Policy:

DeviceEvents
| where ActionType == "SmartScreenUrlWarning"
| extend ParsedFields = parse_json(AdditionalFields)
| project DeviceName, ActionType, Timestamp, RemoteUrl, InitiatingProcessFileName,
          Experience = tostring(ParsedFields.Experience)
| where Experience == "CustomPolicy"

SmartScreen & Phishing Protection

Microsoft Defender SmartScreen ist eine cloudbasierte Komponente und fester Bestandteil von Windows – technisch also nicht Teil von Defender for Endpoint, aber eng mit ihm verzahnt. SmartScreen begann als „Phishing-Filter" im Internet Explorer 7 und filtert seit IE 8 auch Social-Engineering-Malware. Heute ist es in Internet Explorer (Legacy), Windows-Explorer, Microsoft Edge und – ab Windows 11 22H2 – mit Enhanced Phishing Protection integriert.

Funktionsweise

SmartScreen schützt vor Phishing, Malware und potenziell unerwünschten Anwendungen:

• Schutz von Websites: Jede besuchte Seite wird gegen einen dynamischen Index bekannter Phishing- und Schadseiten geprüft (gespeist aus Meldungen privater und Unternehmensgeräte). Beim ersten Laden einer unbekannten Seite oder App erfolgt zusätzlich eine Reputationsprüfung.
• Schutz von Downloads: Jeder Download wird gegen eine Liste gemeldeter Malware abgeglichen. Taucht der Dateihash dort auf, warnt SmartScreen. Ist die Datei unbekannt (nicht in der Liste häufig heruntergeladener Dateien), wird ebenfalls gewarnt. Dieser Mechanismus ist direkt in Windows 10/11 verankert.

Zusammenhang mit Network Protection

Entscheidend ist das Zusammenspiel mit Network Protection: In Microsoft Edge ist SmartScreen direkt eingebettet und übernimmt Inhaltsfilterung, Custom Indicators und Cloud-App-Regeln. Bei Drittanbieter-Browsern (Chrome, Firefox, Opera) nutzt MDE ausschließlich Network Protection ohne SmartScreen.

Ist bei Edge nur Network Protection aktiv, aber SmartScreen deaktiviert, besteht kein Schutz im Browser.

In Edge übernimmt SmartScreen die Filterung; bei Drittanbieter-Browsern greift ausschließlich Network Protection.

Blockierungsbeispiel durch SmartScreen in Microsoft Edge.

Bei Drittanbieter-Browsern wie Chrome greift Network Protection – ohne SmartScreen.

Der Zusammenhang je Szenario:

Konfiguration mit Intune (Basis für Edge & Explorer)

SmartScreen-Einstellungen finden sich in Intune an mehreren Stellen (Security Baselines, Geräteeinschränkungsprofile, Settings Catalog, Endpoint-Security-Profile). Es empfiehlt sich, alle Einstellungen einer Funktion in einem Profil zu bündeln, um Konflikte zu vermeiden.

Für die Basiseinstellungen legt man ein Profil vom Typ Settings Catalog an (Plattform: Windows 10 und höher) und sucht unter Add settings nach „Defender SmartScreen". Relevante Werte:

Links die SmartScreen-Richtlinie für den Datei-Explorer, mittig die Edge-SmartScreen-Einstellungen, rechts die auswählbaren Richtlinien.

So sieht das Block-Ergebnis von SmartScreen im Edge-Browser aus.

Warnmodus: „Warnen und Überspringen verhindern" vs. „Warnen"

SmartScreen bietet zwei Verhaltensmodi:

• Warnen und Überspringen verhindern (empfohlen): Der Anwender kann die Warnung nicht umgehen. Beim gefährlichen Download bleibt nur „Löschen"; eine als schädlich erkannte Website zeigt eine rote Sperrseite mit „Zurück"-Button. Riskante Aktionen lassen sich nicht erzwingen.
• Warnen: Es erscheint dieselbe Warnung, der Nutzer kann sie aber überspringen – etwa per „Beibehalten" beim Download oder „Trotzdem fortfahren (nicht empfohlen)" bei einer Website.

Im empfohlenen Modus bleibt bei einem gefährlichen Download nur die Option „Löschen".

Eine als gefährlich erkannte Website wird mit einer roten Sperrseite und „Zurück"-Button blockiert.

Im Modus „Warnen" kann der Nutzer den Download über „Beibehalten" trotzdem öffnen.

Ebenso lässt sich die Website über „Trotzdem fortfahren (nicht empfohlen)" aufrufen.

Enhanced Phishing Protection (Windows 11 22H2)

Seit Windows 11 22H2 gibt es den erweiterten Phishing-Schutz. Er schützt vor allem Arbeits- und Schulkonten: Gibt ein Nutzer sein Unternehmenspasswort etwa in Notepad oder einer Office-App ein, erscheint eine Warnung, dass es unsicher ist, das Passwort in dieser App zu speichern.

Die Einstellungen gehören zum Defender-Richtlinientyp WebThreatDefense. Man legt dazu ein Settings-Catalog-Profil an (Windows 10 und höher) und fügt unter Add settings die Kategorie Enhanced Phishing Protection hinzu:

Unter „Add settings" die Kategorie Enhanced Phishing Protection auswählen und die Notify-Optionen aktivieren.

Alle „Notify"-Funktionen sollten aktiviert sein, damit der Nutzer die entsprechenden Warnungen erhält.

Testen und Hunting

Zum Testen stellt Microsoft die Demo-Site demo.wd.microsoft.com bereit. Dort lassen sich URL-Reputation (Phishing- und Malware-Seiten, blockierter Download) und Anwendungs-Reputation (unbekanntes Programm mit Umgehung, bekannte Malware mit Blockierung) durchspielen. Enhanced Phishing Protection prüft man, indem man ein Arbeitskennwort in einer unsicheren App eingibt oder auf einer Website wiederverwendet – jeweils erscheint eine Sicherheitswarnung.

Notify Unsafe App: Gibt der Nutzer sein Arbeitskennwort in einer App wie Notepad ein, warnt SmartScreen.

Notify Password Reuse: Bei erneuter Verwendung des Arbeitskennworts empfiehlt die Warnung, das Passwort zu ändern.

Auf der Demo-Site lassen sich Phishing- und Malware-Seiten sowie blockierte Downloads durchspielen.

Ebenso testbar: unbekannte Programme (Warnung mit Umgehung) und bekannte Malware (Blockierung).

In Advanced Hunting stehen die ActionTypes SmartScreenAppWarning, SmartScreenUrlWarning, SmartScreenExploitWarning und SmartScreenUserOverride in der Tabelle DeviceEvents zur Verfügung:

DeviceEvents
| where ActionType has_any('SmartScreenAppWarning','SmartScreenUrlWarning')
| extend TriggerReason = parse_json(AdditionalFields).Experience

Das Feld AdditionalFields enthält als Experience u. a. Werte wie Untrusted, Phishing, Malicious, Exploit oder CustomBlockList, die den Grund der Warnung beschreiben.

Controlled Folder Access

Der überwachte Ordnerzugriff (Controlled Folder Access, CFA) schützt wichtige Dateien vor Ransomware, indem nur vertrauenswürdige Anwendungen in geschützte Ordner schreiben dürfen. Microsoft pflegt dafür eine Liste bekannter System-App-Speicherorte, die automatisch als vertrauenswürdig gelten. Gerade gegen Ransomware ist CFA wirksam, weil ungewöhnliche Prozesse Dateien nicht verschlüsseln können.

Standardmäßig geschützte Ordner unter Windows:

C:\Users\<Benutzername>\Documents
C:\Users\Public\Documents
C:\Users\<Benutzername>\Pictures
C:\Users\Public\Pictures
C:\Users\Public\Videos
C:\Users\<Benutzername>\Videos
C:\Users\<Benutzername>\Music
C:\Users\Public\Music
C:\Users\<Benutzername>\Favorites

Konfiguration mit Intune

CFA wird über ein Endpoint-Security-Profil unter Attack Surface Reduction gesteuert. Dort setzt man Enable Controlled folder access auf Enabled oder Audit und kann anschließend über Protected Folders eigene Ordner ergänzen bzw. über Allowed Applications zusätzliche vertrauenswürdige Programme freigeben.

Enable Controlled Folder Access auf „Enabled" setzen; über Protected Folders und Allowed Apps folgen bei Bedarf weitere Anpassungen.

Konfiguration mit PowerShell

# Aktiviert (Block-Modus)
Set-MpPreference -EnableControlledFolderAccess Enabled

# Audit-Modus
Set-MpPreference -EnableControlledFolderAccess AuditMode

Hunting

Auditierte oder blockierte Zugriffe findet man über:

DeviceEvents
| where ActionType in ('ControlledFolderAccessViolationAudited','ControlledFolderAccessViolationBlocked')

Auch hier gilt: mit dem Audit-Modus starten und erst nach der Testphase auf Block umschalten. Häufig müssen für Unternehmens-Apps Ausnahmen definiert werden – über Advanced Hunting prüft man, ob unerwünschte Blockierungen auftreten, und passt die Regeln entsprechend an.

Credential Guard

Microsoft Defender Credential Guard nutzt die Virtualization-based Security (VBS) von Windows, um Anmeldeinformationen wie NTLM-Hashes und Kerberos Ticket-Granting-Tickets in einer isolierten, geschützten Umgebung zu speichern. Nur privilegierte Systemprozesse dürfen auf diese Geheimnisse zugreifen – dadurch werden Pass-the-Hash- und Pass-the-Ticket-Angriffe massiv erschwert.

Konfiguration mit Intune

Credential Guard aktiviert man über die Richtlinie Account Protection. In Endpoint Manager geht man zu Endpoint Security → Account Protection, erstellt ein Profil vom Typ Account protection und findet unter den Konfigurationseinstellungen die Option Turn on Credential Guard.

Unter Endpoint Security → Account Protection ein Profil vom Typ „Account protection" erstellen.

Empfohlen wird die Variante „Enable with UEFI lock": Der UEFI-Lock verhindert, dass Credential Guard nachträglich – etwa durch einen Angreifer – wieder deaktiviert wird.

Die Variante „Enable with UEFI lock" verhindert das nachträgliche Deaktivieren von Credential Guard.

Credential Guard sollte auf allen unterstützten Systemen aktiviert werden; es schützt effektiv vor dem Diebstahl von Zugangsdaten. Details zu Voraussetzungen und alternativen Bereitstellungsoptionen liefert die Microsoft-Dokumentation.

Device Control

Mit Device Control steuert MDE den Zugriff auf Wechseldatenträger und andere Peripherie – vom vollständigen Blockieren aller USB-Speicher bis zur gezielten Freigabe einzelner Geräte. Die Bausteine werden in Intune unter Endpoint Security → Attack Surface Reduction über Reusable Settings definiert und in einer Policy zusammengeführt.

Reusable Settings und PrimaryIDs

Für pauschale Block-Regeln legt man Reusable Settings mit einer PrimaryID an. Verfügbar sind unter anderem:

• RemovableMediaDevices
• CdRomDevices
• WpdDevices
• PrinterDevices

Reusable Settings werden in Intune unter ASR angelegt und tragen jeweils eine PrimaryID.

Sollen einzelne USB-Geräte erlaubt werden, geschieht das ebenfalls über Reusable Settings – dabei trägt man die IDs bzw. Seriennummern der Geräte ein. Müssen für ein Gerät mehrere Zustände (z. B. Read, Write, Execute) einzeln gesteuert werden, empfiehlt sich pro USB-Gerät ein eigenes Reusable Setting.

Policy-Aufbau (Block mit Ausnahmen)

Ein typisches Szenario – „alles blockieren, ausgewählte USB-Geräte erlauben":

In der Policy werden die zuvor angelegten Reusable Settings zusammengeführt.

• Included Devices: RemovableMediaDevices auswählen, damit grundsätzlich alle Wechseldatenträger erfasst werden.
• Excluded Devices: die Reusable Settings der erlaubten USB-Geräte auswählen – sie sind vom Block ausgenommen.
• Access: die Aktionen Deny und Audit Deny definieren. Diese gelten für alle Included Devices, während die Excluded Devices davon ausgenommen bleiben.

Included Devices erfassen alle Wechseldatenträger, Excluded Devices nehmen die erlaubten USB-Geräte aus.

Unter „Access" werden die Deny- und Audit-Deny-Aktionen für die Included Devices festgelegt.

Optional lässt sich eine SID einer Benutzergruppe hinterlegen, sodass Deny- oder Allow-Regeln nur für bestimmte Nutzergruppen greifen. Im einfachen Szenario ist das nicht nötig.

Bereitstellung prüfen und Hunting

Ob die aktuelle Policy auf einem Gerät angekommen ist, prüft man als Administrator mit:

Get-MpComputerStatus

Get-MpComputerStatus gibt an, ob die aktuelle Policy auf dem Zielgerät angewendet wurde.

Ausgelöste Device-Control-Ereignisse lassen sich über Advanced Hunting auswerten:

DeviceEvents
| extend parsed = parse_json(AdditionalFields)
| extend MediaClass = tostring(parsed.ClassName)
| extend MediaDeviceId = tostring(parsed.DeviceId)
| extend MediaDescription = tostring(parsed.DeviceDescription)
| extend SerialNumberId = tostring(parsed.SerialNumber)
| extend RemovableStoragePolicy = tostring(parsed.RemovableStoragePolicy)
| extend RemovableStorageAccess = tostring(parsed.RemovableStorageAccess)
| extend RemovableStoragePolicyVerdict = tostring(parsed.RemovableStoragePolicyVerdict)
| extend PID = tostring(parsed.ProductId)
| extend VID = tostring(parsed.VendorId)
| extend VID_PID = strcat(VID,"_",PID)
| extend InstancePathId = tostring(parsed.DeviceInstanceId)
| where ActionType == "RemovableStoragePolicyTriggered"
| project Timestamp, RemovableStoragePolicy, RemovableStorageAccess, RemovableStoragePolicyVerdict,
          SerialNumberId, VID, PID, VID_PID, InstancePathId
| order by Timestamp desc

Die Abfrage liefert je ausgelöstem Ereignis Policy, Verdict, Seriennummer sowie VID/PID des Geräts.

Nächster Teil der Serie: Security Baselines.