Wenn Sie identitätsbasierte Bedrohungen manuell bearbeiten, kostet das Zeit und kann Ihr Risiko sogar erhöhen. Möglicherweise fließen sensible Daten ab und bringen Ihr Unternehmen in Gefahr. Mehr Schutz erreichen Sie zum Beispiel, indem Sie Microsoft Conditional Access (CA) mit Graph-API-Triggern und PowerShell-Automatisierung kombinieren. Das Ergebnis ist eine automatisierte Bedrohungsabwehr.
So können MSPs (Managed Services Provider) Bedrohungen eindämmen und entschärfen, ohne auf teure SIEM-Plattformen (Security Information and Event Management) angewiesen zu sein.
Bedrohungsabwehr mit Conditional Access, Microsoft Graph und PowerShell automatisieren
Es gibt verschiedene Wege, die Bedrohungsabwehr zu automatisieren. Sie können Conditional-Access-Richtlinien konfigurieren, Microsoft Graph nutzen, ein PowerShell-Skript schreiben, Ereignisse der Bedrohungsabwehr in der Registry protokollieren und per GPO ein Quarantäne-Verhalten erzwingen.
📌 Voraussetzungen:
- Azure AD Premium P2 für Identity Protection und Conditional Access
- Microsoft Defender for Endpoint oder eine vergleichbare risikobasierte Signalquelle
- Berechtigungen für die Microsoft Graph API
- PowerShell 7+ mit installiertem Microsoft.Graph-Modul
📌 Empfohlene Vorgehensweisen für die Umsetzung:
Klicken Sie, um eine Methode zu wählen | 💻 Am besten für Einzelbenutzer:innen | 💻💻💻 Am besten für Unternehmen |
| Methode 1: Conditional-Access-Richtlinien für die Bedrohungsabwehr konfigurieren | ✓ | |
| Methode 2: Mit Microsoft Graph Richtlinienaktionen in Echtzeit auslösen | ✓ | |
| Methode 3: Behebung mit PowerShell automatisieren | ✓ | |
| Methode 4: Ereignisse der Bedrohungsabwehr in der Registry protokollieren | ✓ | |
| Methode 5: Quarantäne-Verhalten auf risikobehafteten Geräten per GPO erzwingen | ✓ |
Methode 1: Conditional-Access-Richtlinien für die Bedrohungsabwehr konfigurieren
Im ersten Schritt konfigurieren Sie die Conditional-Access-Richtlinien.
📌 Anwendungsfall: IT-Administrator:innen erstellen Conditional-Access-Regeln, die risikobehaftete Anmeldungen automatisiert blockieren oder zusätzlich absichern
Erstellen Sie in Entra ID Conditional-Access-Richtlinien für Bedrohungssignale:
- Reaktion auf Basis des Benutzerrisikos:
- Signal: UserRiskLevel = High
- Aktion: Zugriff blockieren oder Passwortzurücksetzung verlangen
- Reaktion auf Basis des Geräterisikos:
- Signal: DeviceRiskLevel = High (aus Defender)
- Aktion: Konformes Gerät verlangen oder Zugriff blockieren
Beispiel für einen Richtlinienfilter-Ausdruck:
(device.deviceOwnership -eq „Company“) and (device.riskLevel -eq „High“)
Weisen Sie die Richtlinien risikoanfälligen Rollen zu, etwa Administrator:innen und Führungskräften.
⚠️ Warnung: Zu restriktive Regeln können Administrator:innen und andere berechtigte Benutzer:innen aussperren. (Weitere Informationen finden Sie unter: Worauf Sie achten sollten)
Methode 2: Mit Microsoft Graph Richtlinienaktionen in Echtzeit auslösen
Mit Microsoft Graph können Sie Richtlinienaktionen in Echtzeit auslösen.
📌 Anwendungsfall: IT-Administrator:innen erstellen ein Skript, das risikobehaftete Benutzer:innen abfragt und deren Konten in Echtzeit deaktiviert
- Drücken Sie Win, geben Sie PowerShell ein und klicken Sie auf Als Administrator ausführen.
- Kopieren Sie die folgenden Skripte, fügen Sie sie in die Eingabeaufforderung ein und drücken Sie die Eingabetaste:
Connect-MgGraph -Scopes "User.ReadWrite.All", „IdentityRiskEvent.Read.All“
foreach ($user in $riskyUsers) { Update-MgUser -UserId $user.Id -AccountEnabled:$false Write-Output „Disabled account: $($user.UserPrincipalName)“ } |
💡 Tipp: Protokollieren Sie die Aktion und benachrichtigen Sie optional eine:n Administrator:in oder eröffnen Sie ein PSA-Ticket, damit die Sicherheitsteams den Überblick behalten.
Methode 3: Behebung mit PowerShell automatisieren
Mit PowerShell verwandeln Sie Risikoerkennungen in wiederholbare, nachvollziehbare Aktionen.
📌 Anwendungsfall: IT-Administrator:innen automatisieren die Kontowiederherstellung, indem sie nach Erkennungen mit hohem Risiko Passwortzurücksetzungen erzwingen, Token entwerten und Geräte in Quarantäne verschieben
Sie können zum Beispiel MFA (Multi-Factor Authentication) zurücksetzen und per PowerShell eine Passwortzurücksetzung auslösen.
- Drücken Sie Win, geben Sie PowerShell ein und klicken Sie auf Als Administrator ausführen.
- Kopieren Sie die folgenden Skripte, fügen Sie sie in die Eingabeaufforderung ein und drücken Sie die Eingabetaste:
Connect-MgGraph -Scopes "User.ReadWrite.All", „IdentityRiskyUser.ReadWrite.All“, „Device.ReadWrite.All“
foreach ($user in $riskyUsers) { try { # Invalidate all active sessions Invoke-MgInvalidateUserRefreshToken -UserId $user.Id # Force password reset on next sign-in (requires a temporary password)
Update-MgUser -UserId $user.Id -PasswordProfile @{ Password = $tempPassword ForceChangePasswordNextSignIn = $true } # Quarantine associated device(s) if extension attribute exists $devices = Get-MgUserRegisteredDevice -UserId $user.Id foreach ($device in $devices) { try { Update-MgDevice -DeviceId $device.Id -AdditionalProperties @{ „extensionAttribute1“ = „Quarantined“ } } catch { Write-Warning „Failed to update device $($device.Id)“ } } Write-Output „Remediated: $($user.UserPrincipalName)“ } catch { Write-Warning „Failed to remediate user $($user.UserPrincipalName)“ } } |
- Gerät per Tag oder Richtlinienfilter in Quarantäne verschieben:
| Update-MgDevice -DeviceId $device.Id -AdditionalProperties @{ „extensionAttribute1“ = „Quarantined“ } |
💡 Tipp: Sie können diese Skripte mit RMM-Aufgaben kombinieren oder über E-Mail-Alarmierungen und Logic Apps auslösen.
⚠️ Warnung: Bevor Sie die geänderten Einstellungen auf verschiedenen Endpunkten ausrollen, sollten Sie sie zuerst auf einem lokalen Rechner testen. (Weitere Informationen finden Sie unter: Worauf Sie achten sollten)
Methode 4: Ereignisse der Bedrohungsabwehr in der Registry protokollieren
Bei dieser Methode werden lokale Reaktionsereignisse in der Registry protokolliert, und zwar für Geräte, die nicht von Microsoft Defender oder Intune abgedeckt sind.
📌 Anwendungsfall: IT-Administrator:innen protokollieren Aktivitäten der Bedrohungsabwehr in der Windows-Registry, um lokale Audit-Trails zu führen
- Drücken Sie Win, geben Sie PowerShell ein und klicken Sie auf Als Administrator ausführen.
- Kopieren Sie die folgenden Skripte, fügen Sie sie in die Eingabeaufforderung ein und drücken Sie die Eingabetaste:
New-Item -Path "HKLM:\SOFTWARE\Org\ThreatResponse" -Force
|
Sie können auch prüfen, was in dem Registry-Schlüssel steht, indem Sie den folgenden Befehl kopieren und einfügen:
| reg query HKLM\SOFTWARE\Org\ThreatResponse |
⚠️ Warnung: Änderungen an der Registry können unbeabsichtigte Folgen haben. Gehen Sie vorsichtig vor und sichern Sie die Registry, bevor Sie Änderungen vornehmen. (Weitere Informationen finden Sie unter: Worauf Sie achten sollten)
Methode 5: Quarantäne-Verhalten auf risikobehafteten Geräten per GPO erzwingen
Mit GPO können Sie Einschränkungen erzwingen, sobald lokale Registry-Schlüssel eine Quarantäne anzeigen.
📌 Anwendungsfall: IT-Administrator:innen erzwingen die Quarantäne von Endpunkten, indem sie Internetzugang und Anwendungen sperren, sobald die Registry einen Quarantänezustand meldet
📌 Voraussetzung: GPO-Zugriff für lokale Quarantäne-Richtlinien
- Drücken Sie Win + R, geben Sie gpmc.msc ein und drücken Sie die Eingabetaste.
- Navigieren Sie zu folgendem Pfad:
- Computerkonfiguration > Windows-Einstellungen > Sicherheitseinstellungen > Richtlinien für Softwareeinschränkung
In diesem Beispiel können Sie den Zugriff auf verbundene Netzlaufwerke einschränken oder Internetbrowser blockieren.
Sie können außerdem ein Quarantäne-Flag in der Registry prüfen und auf dem Endpunkt entsprechend handeln. Führen Sie dazu das folgende Skript in PowerShell aus:
| Script logic (triggered by key):
} |
⚠️ Worauf Sie achten sollten
| Risiken | Mögliche Folgen | Rückgängig machen |
| Restriktive Regeln können berechtigte Benutzer:innen blockieren | Administrator:innen können ausgesperrt werden. | Richtlinie in Entra ID deaktivieren oder löschen. |
| Kein Test auf einem lokalen Rechner | Wird ein ungetestetes Skript ausgerollt, können Geräte abstürzen, etwa weil Registry-Schlüssel nicht kompatibel sind. | Nehmen Sie die gewünschten Änderungen auf einem lokalen Rechner vor und prüfen Sie dann, ob die Konfiguration das gewünschte Ergebnis liefert. |
| Registry ohne Sicherung bearbeiten | Falsche Änderungen an der Registry können zu Beschädigungen führen. Legen Sie deshalb vorab eine Sicherung an. | Exportieren Sie den Registry-Schlüssel vor den Änderungen über Datei > Exportieren. |
Weitere Überlegungen
Für einen belastbaren Identitätsschutz sollten Unternehmen auf präzises Targeting, klare Eskalationswege, mandantenübergreifende Transparenz und eine sorgfältige Prüfung der Bedrohungssignale setzen.
Bereichsfilter
Wenden Sie CA-Richtlinien nicht auf Benutzer:innen an, die gar nicht betroffen sind, denn das führt zu Störungen. Wenn Sie etwa eine strikte Blockierungsrichtlinie erzwingen, sperren Sie womöglich versehentlich Administrator:innen oder Dienstkonten aus. Nutzen Sie stattdessen Gruppen, Attribute oder Verwaltungseinheiten, um CA-Richtlinien gezielt nur auf Gruppen mit hohem Risiko anzuwenden.
Eskalationswege
Ohne Eskalationsprozess bleiben manche Signale unbeachtet, oder kritische Alarmierungen blockieren Benutzer:innen, ohne dass eine Behebung erfolgt. Hier hilft eine Ticketing-Integration für Nachverfolgung und Untersuchung. Dazu leiten Sie risikobehaftete Anmeldungen und blockierte Zugriffsversuche weiter oder übernehmen die Risikoerkennungen von Identity Protection direkt in ein Ticketing-System.
Mandantenübergreifende Alarmierung
Fehlende Transparenz über Umgebungen hinweg erschwert MSPs die Verwaltung mehrerer Mandanten. Für eine bessere mandantenübergreifende Überwachung bieten sich Graph-API-Schleifen oder Logic Apps an:
- Graph-API-Schleifen: Fragen Sie Microsoft Graph in jedem verwalteten Mandanten ab, um Alarmierungs- und Anmeldedaten zu sammeln.
- Logic Apps: Automatisieren Sie das Sammeln und Weiterleiten von Alarmierungen an ein zentrales SIEM.
Bedrohungssignale validieren
CA kann Richtlinien auf Basis von Signalen aus Microsoft Defender, Entra ID und Identity Protection durchsetzen. Dennoch kommt es zu Fehlalarmen, und eine Umsetzung allein auf Basis dieser Signale kann zu unnötigen Sperrungen führen. Eine Möglichkeit, das zu vermeiden: Verlangen Sie mehr als ein Risikosignal, bevor eine Blockierung ausgelöst wird.
Häufige Probleme beheben
Im Folgenden finden Sie typische Probleme bei der automatisierten Bedrohungsabwehr und passende Lösungen.
Graph-Fehler
Treten Graph-Fehler auf, prüfen Sie am besten die delegierten Berechtigungen und die App-Token-Berechtigungen. Dekodieren Sie sowohl die delegierten Token als auch die App-Token und achten Sie auf Muster. Der Code 401 deutet auf Token-Probleme hin, 403 auf unzureichende Berechtigungen.
Verzögerte Richtlinien
Graph-basierte Updates brauchen manchmal einige Minuten, bis sie greifen. Prüfen Sie das daher anhand der Anmeldeprotokolle. Sinnvoll ist außerdem, die Protokolle zu auditieren und zu bestätigen, dass Ihre Graph-Änderung abgeschlossen ist.
GPO wird nicht ausgelöst
Wird die GPO nicht ausgelöst, prüfen Sie das Aktualisierungsintervall der Richtlinie und den Ausführungskontext des Skripts. Sie können eine Aktualisierung auch erzwingen, indem Sie gpupdate /force ausführen.
NinjaOne-Services für die automatisierte Bedrohungsabwehr
Mit NinjaOne skalieren MSPs ihre Reaktions-Workflows auch in hybriden und nicht Microsoft-nativen Umgebungen. Die NinjaOne-Services unterstützen die automatisierte Bedrohungsabwehr, indem sie:
- Skripte ausrollen, um kompromittierte Geräte zu isolieren oder zu kennzeichnen
- Registry-Schlüssel und Risikoindikatoren überwachen, um eine Behebung auszulösen
- Endpunkte für die Richtlinienzuweisung taggen
- Alarmierungen und Workflow-Automatisierung auf Basis von Skriptergebnissen auslösen
- Mandantenübergreifend über Ereignisse der Bedrohungsabwehr, durchgeführte Aktionen und betroffene Endpunkte berichten
Verweildauer bei einer Kompromittierung durch automatisierte Bedrohungsabwehr verkürzen
Wer die Bedrohungsabwehr mit Microsoft Conditional Access, Graph API und PowerShell automatisiert, kann als MSP Risiken eindämmen, ohne teure SIEM-Tools einzusetzen. Zusätzlich lässt sich die Automatisierung mit Tools wie NinjaOne ausbauen: Skripte ausrollen, Endpunkte überwachen und die mandantenübergreifende Transparenz und Berichterstattung vereinfachen.
Verwandte Themen:
- Was ist SOAR (Security, Orchestration, Automation, and Response)?
- MDR vs. XDR: Wo liegt der Unterschied?
- Was ist Einheitliches Bedrohungsmanagement (UTM)?
- Schwachstellenmanagement automatisieren: So geht’s
- Ransomware erkennen: 12 Möglichkeiten zur Überwachung & Alarmierung, die Sie automatisieren können
