Das Inventar für Browser-Erweiterungen in Defender deckt Risiken auf

Viele Unternehmen stecken viel Zeit ins Patch-Management und verlieren dabei Browser-Erweiterungen und Zertifikate aus den Augen. In den letzten Monaten habe ich in mehreren Tenants erlebt, dass Browser-Add-ons mit weitreichenden Berechtigungen und selbstsignierte Zertifikate echte Schwachstellen aufgerissen haben. Im Betriebsalltag bleibt so etwas meist lange unbemerkt. Ein genauer Blick ins Inventar von Microsoft Defender Vulnerability Management (DVM) lohnt sich deshalb, denn die neuen Ansichten für Browser-Erweiterungen und Zertifikate zeigen endlich, was tatsächlich auf den Endpunkten installiert ist und wo dringend etwas zu tun ist.

Bei Browser-Erweiterungen liegt das Risiko in den Berechtigungen

Im Defender-Portal unter Endpoints → Vulnerability management → Inventories → Browser extensions gibt es seit einiger Zeit eine kompakte Übersicht aller erkannten Add-ons in Microsoft Edge, Google Chrome und Mozilla Firefox, jeweils mit Version, Publisher, Berechtigungen und Installationspfad. Sobald man in die Details geht, springt das Problem oft direkt ins Auge. Erweiterungen, die auf sämtliche Webseiten zugreifen oder Daten abfließen lassen könnten, sind nach wie vor weit verbreitet. Laut aktueller Ankündigung brauchen einige Ansichten und Detailfunktionen entweder das Add-on Defender Vulnerability Management oder Defender for Endpoint Plan 2 plus Add-on. Meiner Erfahrung nach finden sich selbst in Umgebungen mit strengen Richtlinien erstaunlich viele unerwünschte Erweiterungen, vor allem dann, wenn Software von Drittanbietern still und leise Add-ons für Edge oder Chrome mitinstalliert.

Wenn ich genauer hinsehen will, nutze ich meist Advanced Hunting (Defender-Portal → Hunting → Advanced hunting, Rolle: mindestens Sicherheitsleser), zum Beispiel mit dieser Abfrage:

DeviceTvmBrowserExtensions
| summarize count() by ExtensionName, Publisher, Permissions
| sort by count_ desc

Damit erkenne ich sofort, welche Erweiterungen mit gefährlichen Berechtigungen im Unternehmen am häufigsten vorkommen. Welche Felder es gibt und was sich damit anfangen lässt, beschreibt die offizielle Dokumentation von Microsoft. Ich filtere am liebsten zuerst nach „All Sites“ oder „clipboard“, weil dort häufig das größte Risiko steckt.

Ein Tipp aus der Praxis: Wer im Unternehmen Microsoft Edge einsetzt, sperrt riskante Erweiterungen am effizientesten über Intune, und zwar gezielt nach Extension-ID: Intune-Portal → Geräte → Konfigurationsprofile → Einstellungen für Microsoft Edge → „Erweiterungen blockieren“. Bekannte Problemfälle sind so mit wenig Aufwand erledigt.

Das Zertifikatsinventar macht ablaufende, schwach signierte und selbstsignierte Zertifikate sichtbar

Unter Endpoints → Vulnerability management → Inventories → Certificates listet Defender inzwischen auch alle Zertifikate vollständig auf, die auf den Endgeräten gefunden wurden. Bei der Durchsicht stoße ich immer wieder auf dieselben Risikokategorien:

• Zertifikate, die demnächst ablaufen (und dann Ausfälle verursachen)
• Self-Signed-Zertifikate, die sich leicht missbrauchen lassen
• Zertifikate mit schwachen Signaturalgorithmen (z. B. SHA1, abgekündigt)
• Zertifikate, die in nicht verwalteten Zertifikatsspeichern liegen

Selbstsignierte Zertifikate gehören in manchen Software-Stacks leider immer noch zum Standard, und Angreifer bewegen sich mit ihrer Hilfe gern seitlich durchs Netzwerk. Alle Felder und Filter beschreibt die offizielle Dokumentation zum Zertifikatsinventar.

Advanced Hunting leistet auch hier gute Dienste (Aufruf wie oben). Diese Beispielabfrage liefert alle Zertifikate, die bald ablaufen oder schwach signiert sind:

DeviceTvmCertificateInfo
| where SignatureAlgorithm in ('sha1RSA', 'md5RSA') or ExpirationDate < now() + 30d
| project DeviceName, Subject, Issuer, ExpirationDate, SignatureAlgorithm

In mehreren Projekten bin ich so auf Zertifikate gestoßen, die kurz vor dem Ablauf standen oder noch mit SHA1 signiert waren. Im laufenden Betrieb sind das echte Zeitbomben.

Ein Diagramm zeigt den Weg vom Fund bis zur Gegenmaßnahme

Damit klar wird, wie ein Risiko von der Entdeckung bis zur Behebung durchs Unternehmen läuft, habe ich den Ablauf in einem einfachen Flussdiagramm festgehalten:

flowchart TD
    Entdeckung["Inventar: Erweiterung/Zertifikat entdeckt"] --> Analyse["Risikoanalyse im Portal oder Hunting"]
    Analyse --> Entscheidung["Blockieren, Entfernen oder Ignorieren?"]
    Entscheidung --> Block["Blockieren via Intune/Edge Policy"]
    Entscheidung --> Entfernen["Manuell entfernen/lassen"]
    Entscheidung --> Dokumentation["Dokumentieren/Ausnahme"]

Abbildung: Vom Fund im Inventar bis zur Abwehrmaßnahme im Unternehmen.

Richtlinien und feste Prozesse machen aus dem Inventar echte Kontrolle

Mit dem Inventar fängt die Arbeit erst an, entscheidend ist die konsequente Umsetzung danach. Bei Browser-Erweiterungen fahre ich im Alltag gut damit, zunächst alle riskanten Add-ons zentral zu sperren (Edge per Intune-Policy, Chrome per GPO oder Google Admin Console). Wer mehrere Browser zulässt, muss doppelt aufpassen und die Richtlinien für jeden erlaubten Browser einzeln umsetzen. Bei Zertifikaten läuft der Prozess oft zäher. Mit dem neuen Inventar fallen offensichtliche Schwachstellen aber fortlaufend auf, und das PKI- oder Client-Management-Team bekommt klare Aufgaben übergeben.

Abgelaufene oder schwache Zertifikate werden allerdings selten automatisch entfernt. Es lohnt sich daher, mindestens einmal im Monat eine feste Prüfroutine einzuplanen oder alte Zertifikate, wo es geht, mit Endpoint-Management-Tools zu löschen.

Für mich gehört das Inventar zum Pflichtprogramm der Cloud-Security

Ich halte das Inventar der Browser-Erweiterungen für ein Thema, das man ernst nehmen muss. In jeder Umgebung, in der Clients verwaltet werden, gehört es für mich zum Pflichtprogramm und nicht zur Kür. Zu viele Angriffe setzen gezielt bei schwacher Browser-Sicherheit oder bei Zertifikaten an. Immerhin stehen die Werkzeuge jetzt bereit und sind vergleichsweise schnell eingerichtet. Wer das Thema einmal sauber in Monitoring und Betrieb verankert, senkt das Risiko spürbar und erlebt bei Audits und in der Incident Response deutlich weniger böse Überraschungen.