Der Manipulationsschutz verhindert das Abschalten von Defender

In vielen Umgebungen, die ich betreue, gehört der Manipulationsschutz in Defender (Tamper Protection) längst zur Grundhygiene und ist kein optionales Extra mehr. In Microsoft Defender for Endpoint und Defender Antivirus soll er verhindern, dass lokale Admins einfach den Echtzeitschutz oder die Cloud-Analyse abschalten oder eigene Ausnahmen anlegen. Noch heikler wird es, wenn normale Nutzer mit eskalierten Rechten oder Angreifer nach einem Initialzugriff dasselbe versuchen. Ohne diesen Schutz gelingt das erschreckend oft. Dann sind Virenschutz und weitere Schutzmechanismen ausgehebelt, und für Ransomware und Co. ist der Weg frei.

Der Manipulationsschutz sperrt zentrale Defender-Einstellungen gegen lokale Änderungen

Genau hier setzt der Manipulationsschutz an. Solange er aktiv ist, können weder lokale Admins noch Angreifer zentrale Schutzfunktionen abschalten, egal ob über die Registrierung, PowerShell, Gruppenrichtlinien oder die Benutzeroberfläche. Besonders geschützt sind der Echtzeitschutz, der Cloud-Schutz, IOAV (Schutz bei Dateioperationen) sowie das Hinzufügen oder Entfernen von Ausnahmen in Defender Antivirus. Änderungen laufen dann nur noch über zentrale Werkzeuge, etwa über Intune-Endpoint-Security-Richtlinien oder direkt im Microsoft Defender Portal. Wer tiefer einsteigen will, findet in der offiziellen Microsoft-Dokumentation zum Manipulationsschutz eine gut verständliche Beschreibung.

In der Praxis begegnen mir dazu immer wieder Missverständnisse. Der Manipulationsschutz ersetzt weder ein Berechtigungskonzept noch eine moderne Angriffserkennung. Er ist eine zusätzliche Verteidigungslinie, allerdings eine wichtige. Ich habe mehrfach erlebt, dass Angreifer nach dem Initialzugriff zuerst Defender deaktiviert haben, denn das gehört zu ihren beliebtesten Techniken. Fehlt der Manipulationsschutz, haben sie leichtes Spiel.

Der Manipulationsschutz lässt sich tenant-weit oder gezielt per Intune aktivieren

Für alle verwalteten Geräte lässt sich der Manipulationsschutz tenant-weit einschalten. Das erledige ich im Defender-Portal unter Einstellungen → Endpunkte → Erweiterte Funktionen für die gesamte Organisation, und zwar in klassischen Hybrid-Szenarien genauso wie bei reinen Cloud-Geräten. Wer feiner steuern möchte, rollt ihn per Intune aus. Dazu wähle ich in der Intune-Konsole unter Endpoint Security → Antivirus → Erstellen → Windows-Sicherheitsumgebung die Einstellung „Manipulationsschutz“ und weise die Richtlinie bestimmten Gerätegruppen zu. Einzelheiten zur Intune-Integration stehen in der Microsoft-Dokumentation.

Ein Sonderfall verdient besondere Aufmerksamkeit, nämlich der Schutz von Ausnahmen. Damit niemand Defender-Ausnahmen lokal hinzufügen oder ändern kann, müssen die Endpoints über Intune verwaltet werden, und in der AV-Konfiguration muss die Option „DisableLocalAdminMerge“ gesetzt sein. Fehlt eine der beiden Voraussetzungen, bleibt eine kritische Lücke, über die Angreifer weiterhin eigene Ausnahmen einschleusen können. In Audits stoße ich leider noch viel zu oft darauf.

# PowerShell: Manipulationsschutz-Status lokal prüfen
Get-MpComputerStatus | Select-Object IsTamperProtected

Diesen Befehl kann jeder Benutzer in einem lokalen PowerShell-Fenster ausführen. Er zeigt den aktuellen Status des Manipulationsschutzes an und funktioniert auf allen Windows-10/11-Clients mit Defender.

Der Troubleshooting Mode erlaubt kurzfristige Änderungen im Notfall

Natürlich gibt es berechtigte Situationen, in denen ich Einstellungen am Defender-Client kurzfristig anpassen muss, zum Beispiel bei einer dringenden Fehlersuche. Dafür gibt es seit einiger Zeit den „Troubleshooting Mode“. Über das Defender-Portal versetze ich einzelne Geräte gezielt in einen temporären Modus, in dem der Manipulationsschutz für einen festgelegten Zeitraum ausgesetzt ist. Dieses Zeitfenster ist bewusst eng gesteckt, und sämtliche Änderungen werden protokolliert. Wie man den Modus aktiviert und überwacht, ist in der Dokumentation zum Troubleshooting Mode ausführlich beschrieben. In meinen Projekten greife ich nur darauf zurück, wenn es wirklich keine Alternative gibt, und achte dabei stets auf Nachvollziehbarkeit.

Mein Tipp nach jeder Fehlerbehebung: unbedingt kontrollieren, ob der Manipulationsschutz wieder aktiv ist. Das geht schnell mit „Get-MpComputerStatus“ oder direkt im Geräteinventar des Defender-Portals.

Die meisten Lücken entstehen durch vermeidbare Konfigurationsfehler

Diese Stolpersteine begegnen mir in der Praxis besonders häufig:

• Der Manipulationsschutz ist nur tenant-weit aktiviert, die Ausnahmen sind aber nicht abgedeckt (fehlende Intune-Konfiguration)
• Die Geräte werden nicht über Intune verwaltet, deshalb lassen sich die Ausnahmen nicht zentral steuern
• Alte GPOs oder lokale Skripte versuchen weiterhin, Defender-Einstellungen zu überschreiben (das klappt nicht mehr, führt aber zu verwirrenden Fehlermeldungen)
• Jemand aktiviert den Troubleshooting Mode und vergisst ihn anschließend
• Niemand überwacht den AV-Status, sodass Probleme mit dem Manipulationsschutz unbemerkt bleiben

Gerade wenn On-Premises- und Cloud-Verwaltung nebeneinander laufen, sollte man regelmäßig kontrollieren, ob Manipulationsschutz-Richtlinien, Gerätestatus und Ausnahmeverwaltung schlüssig zueinander passen. Im Zweifel hilft es, die Inventare aus Intune und Defender-Portal miteinander abzugleichen.

Ein ausgehebelter Defender macht es Angreifern leicht

Für so zentral halte ich den Manipulationsschutz, weil ich in Angriffssimulationen und ebenso in echten Vorfällen immer wieder beobachte, dass „Defense Evasion“ zu den ersten Schritten gehört. Wer lokale Adminrechte erlangt hat, versucht meist zuerst, Defender abzuschalten oder über Ausnahmen lahmzulegen. Ohne Manipulationsschutz klappt das viel zu leicht. Laufen dann noch Gruppenrichtlinien oder Skripte, die nicht mehr greifen, verliert man schnell den Überblick. Ich rate deshalb, den Manipulationsschutz überall zu aktivieren, wo es möglich ist, und die Statusüberwachung zu automatisieren.

Im folgenden Flussdiagramm ist zu sehen, wie der Manipulationsschutz in Defender mit der zentralen Verwaltung und dem Troubleshooting Mode zusammenspielt:

flowchart TD
    User["Lokaler Admin"] -->|"Versucht Änderung"| Defender["Defender Einstellungen"]
    Defender -->|"Manipulationsschutz aktiv?"| Check["Aktiv: Änderung blockiert"]
    Defender -->|"Troubleshooting Mode aktiv?"| TempChange["Temporäre Änderung erlaubt"]
    TempChange -->|"Nach Ablauf: Schutz wieder aktiv"| Check
    Check -->|"Statusüberwachung"| Portal["Defender Portal/Intune"]

Abbildung: Der Manipulationsschutz blockiert lokale Änderungen, lässt im Troubleshooting Mode jedoch gezielte Ausnahmen zu.

Auf den Manipulationsschutz sollte heute niemand mehr verzichten

Aus meiner Sicht spricht nichts Stichhaltiges mehr dagegen, den Manipulationsschutz in Defender konsequent einzusetzen. Die technischen Voraussetzungen wie Windows 10/11, Defender Antivirus und Intune-Verwaltung sind fast überall vorhanden, und die Gefahr durch Angreifer oder Fehlbedienung ist real. Wer jetzt noch darauf verzichtet, geht ein unnötiges Risiko ein. Es lohnt sich, die eigene Umgebung gründlich durchzusehen und offene Lücken zu schließen. Mehr zum Zusammenspiel von Geräteschutz, Intune und sicheren Admin-Konfigurationen steht in meinen Beiträgen Windows LAPS mit Intune: lokale Admin-Geheimnisse im Griff und Endpoint Privilege Management: lokale Adminrechte im Griff.