Sie wollen mehr?
Weitere Artikel im Archiv
So analysieren Sie Defender-Configs mit Microsoft Intune
Microsoft Intune wurde 2010 vorgestellt und ist Microsofts Endpoint Manager für die Betriebssysteme Android, iOS, macOS und Windows. Intune benötigt keine On-Premise-Infrastruktur und die Administration erfolgt über eine Weboberfläche. Mit der zunehmenden Nutzung von Cloud-Dienstleistungen stellen wir auch einen Wechsel von Gruppenrichtlinien auf Intune für die Verwaltung von Windows-Clients fest.
Traditionellerweise werden Einstellungen über das Group Policy Management auf Systeme verteilt. In der Registry werden diese Einstellungen unter dem Pfad HKLM:\Software\Policies\Microsoft\*
hinterlegt. Intune speichert die Einstellungen auch in den Registry, verwendet jedoch andere Pfade und Schlüssel. Dies führt zu Umstellungen beim Auswerten der Defender-Konfiguration und hat sogar Implikationen für die Sicherheit des Systems.
Eine Funktion von Microsoft Defender for Endpoint ist das Attack-Surface-Reduction-Regelwerk, welches im Labs Artikel vom 23. April 2020 vorgestellt wurde. Jede Regel erhält eine GUID, die Liste aller Regeln befindet sich unter der Attack surface reduction (ASR) rules reference.
Als Beispiel wird die Regel Block all Office applications from creating child processes mit der GUID d4f940ab-401b-4efc-aadc-ad5f3c50688a
verwendet. Mit dieser GUID kann der Status der Regel in der Registry abgefragt werden. Wenn die Konfiguration mittels Gruppenrichtlinien erfolgte, hat jede Regel ihren eigenen Schlüssel.
PS C:\Users\admin> Get-ItemPropertyValue -Path "HKLM:\Software\Policies\Microsoft\Windows Defender\Windows Defender Exploit Guard\ASR\rules" -Name "d4f940ab-401b-4efc-aadc-ad5f3c50688a" 1
Der Wert des Schlüssels d4f940ab-401b-4efc-aadc-ad5f3c50688a
ist 1
, das heisst der Status der Regel ist Block. Der Status des gesamten Regelwerks kann durch die Enumeration aller GUID-Schlüssel abgefragt werden.
Wenn das Regelwerk jedoch mit Intune konfiguriert wurde, gibt es keine Einträge unter diesem Pfad. Intune speichert die Konfigurationseinstellungen im Schlüssel ASRRules
unter dem Pfad HKLM:\Software\Policies\Microsoft\Windows Defender\Policy Manager
. Alle Regeln sind in einem Schlüssel im Format GUID=Setting|GUID=Setting
gespeichert. Für die Auswertung mit HardeningKitty wird daher ein Parsing der Einstellungen durchgeführt um den Status einer spezifischen Regel auszulesen:
$ResultAsr = $Result.Split("|") ForEach ($AsrRow in $ResultAsr) { $AsrRule = $AsrRow.Split("=") If ($AsrRule[0] -eq $Finding.MethodArgument) { $Result = $AsrRule[1] Break } Else { $Result = $Finding.DefaultValue } }
Um die Konfiguration der ASR-Regeln aus der Registry auszulesen, muss bekannt sein, welche Verwaltungslösung verwendet wird. Dies hat auch einen Einfluss auf Frameworks wie CIS Benchmark oder die Microsoft Security Baselines. Beide verwenden für die ASR-Regeln den Pfad für Gruppenrichtlinien, was auf einem mit Intune konfigurierten System zu ungenauen Auswertungen führen kann.
Anstelle der Registry kann zur Auswertung das bereits erwähnte PowerShell-Cmdlet Get-MpPreference
verwendet werden. Das Cmdlet sollte die Einstellungen unabhängig der Verwaltungslösung auslesen können.
Die Ausnahmeregeln von Microsoft Defender Antivirus sind ein interessantes Ziel während der Informationsbeschaffungsphase eines Angriffs. Deshalb hatte Microsoft im Februar 2022 in Windows 11 die Änderung eingeführt, dass das Auslesen von Ausnahmen schwieriger wird. Es sollte nicht mehr möglich sein, die Ausnahmen ohne Administrationsrechte auszulesen. Dies wurde später auch auf Windows 10 portiert.
Für Microsoft Defender Antivirus gibt es drei Einstellungen für Ausnahmen:
Das Auslesen der Ausnahmen mit Get-MpPreference
als Benutzer schlägt fehl:
PS C:\Users\chuck> $DefenderSettings = Get-MpPreference PS C:\Users\chuck> $DefenderSettings.ExclusionPath N/A: Must be and administrator to view exclusions
Die Konfiguration des Antivirus kann zwar ausgelesen werden, die drei Ausnahmenparameter enthalten jedoch keine Resultate. Wenn die gleiche Auswertung mit Administratorenrechten ausgeführt wird, während die Ausnahmen aufgelistet:
PS C:\Users\admin> $DefenderSettings = Get-MpPreference PS C:\Users\admin> $DefenderSettings.ExclusionPath C:\Users\admin\Apps C:\LegacyBusinessApp C:\Temp\insecure
Auf dem System sind drei Ausnahmen konfiguriert. Falls Benutzer in einem der Verzeichnisse Schreibrechte verfügen, kann damit die Prüfung von Dateien des Antivirus umgangen werden. Solange der Benutzer jedoch über keine Administratorenrechte verfügt, bleibt die Einstellung und somit diese Liste der Verzeichnisse unbekannt.
Anstelle des PowerShell-Cmdlets können die Ausnahmeregeln auch aus der Registry ausgelesen werden. Wenn die Defender-Konfiguration über Gruppenrichtlinien erfolgt, können die Einstellungen über folgenden Pfad ausgelesen werden:
PS C:\Users\chuck> $DefenderSettingsRegistry = Get-ChildItem -Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows Defender\Exclusions\" Get-ChildItem : Requested registry access is not allowed. At line:1 char:29 + ... sRegistry = Get-ChildItem -Path "HKLM:\SOFTWARE\Policies\Microsoft\Wi ... + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + CategoryInfo : PermissionDenied: (HKEY_LOCAL_MACH...der\Exclusions\:String) [Get-ChildItem], SecurityException + FullyQualifiedErrorId : System.Security.SecurityException,Microsoft.PowerShell.Commands.GetChildItemCommand
Die Zugriffsrechte des Registry-Schlüssels wurde jedoch so angepasst, dass ein Benutzer keine Rechte hat, diese auszulesen. Als Administrator ist die Abfrage erfolgreich:
PS C:\Users\admin> $DefenderSettingsRegistry = Get-ChildItem -Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows Defender\Exclusions\" PS C:\Users\admin> $DefenderSettingsRegistry.Property C:\Users\admin\Apps C:\LegacyBusinessApp C:\Temp\insecure
Der Zugriffsschutz für Antivirus-Ausnahmeregeln wurde konsequent umgesetzt, weder über die Registry noch über das PowerShell-Cmdlet kann ein Benutzer die konfigurieren Ausnahmen auslesen.
Wenn das System mit Intune konfiguriert wurde, ändert sich die Situation. Analog zum ASR-Regelwerk werden die Antivirus-Einstellungen unter einem anderen Registry-Pfad hinterlegt. Dabei stellt sich heraus, dass der Zugriffsschutz auf die Schlüssel mit den Ausnahmeregeln nicht so strikt implementiert wurde, und ein Benutzer alle Schlüssel auslesen kann.
PS C:\Users\chuck> Get-ItemPropertyValue -Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows Defender\Policy Manager" -Name "ExcludedPaths" C:\Users\admin\Apps|C:\LegacyBusinessApp|C:\Temp\insecure
Bei der Implementierung von Microsoft Intune und der Definition der Registry-Pfade für Microsoft Defender Antivirus ging vergessen, die Zugriffsrechte auf die Schlüssel ebenfalls zu verschärfen. Daher kann ein Benutzer die Ausnahmeregeln auslesen. Diese Information-Leakage-Schwachstelle war im Dezember 2022 möglich, gegebenenfalls hat Microsoft die Zugriffsrechte zu einem späteren Zeitpunkt verschärft.
Die AppLocker-Richtlinie eines Systems kann über das PowerShell-Cmdlet Get-AppLocker-Policy abgefragt werden. Dies ist nur auf einem System möglich, dass über Gruppenrichtlinien konfiguriert wurde. Auf einem System, dass mittels Intune verwaltet wird, liefert die Abfrage keine Werte zurück.
Dafür ist es auf einem durch Intune verwaltenden System möglich die Definitionsdateien der AppLocker-Richtlinie unter dem Pfad C:\Windows\System32\AppLocker\MDM\*
auszulesen. In diesem Verzeichnis ist die Richtline unter anderem als XML-Datei gespeichert. Dadurch kann die AppLocker-Richtline gegebenenfalls unbemerkt ausgelesen werden, falls nur der Aufruf von Get-AppLocker-Policy
überwacht wird.
Es ist abhängig von der Verwaltungslösung unter welchen Registry-Pfaden und -Schlüssel sowie in welchem Format die Konfigurationseinstellungen von Microsoft Defender gespeichert werden. Microsoft wählte für Intune neue Pfade und ein anderes Format, was Auswirkungen bei der Auswertung der Einstellungen für Dokumentationen oder Hardeningempfehlungen hat. Microsoft hat es versäumt, die Zugriffsrechte für die von Intune verwendeten Registry-Schlüssel für Defender-Ausnahmeregeln zu härten, womit eine Information-Leakage-Schwachstelle eingeführt wurde. Diese Schwachstelle muss durch Microsoft behoben werden, von einer Modifikation der Zugriffsrechte der Registry raten wir ab. Die Schwachstelle ist ein Beispiel für die Risiken von Softwareentwicklung, wenn verschiedene Teams am gleichen Produkt arbeiten und kein gegenseitiger Informationsaustausch stattfindet. Idealerweise findet während der gesamten Entwicklung ein Austausch statt, spätestens vor der Veröffentlichung sollten sicherheitsrelevante Punkte nochmals genau geprüft werden.
Wir führen gerne für Sie ein Monitoring des Digitalen Untergrunds durch!
Michael Schneider
Michael Schneider
Michael Schneider
Michael Schneider
Unsere Spezialisten kontaktieren Sie gern!