Zur Navigation Zur Suche Zum Inhalt
    Kontakt

    Sicherheitslücke im Defender-Netzwerkschutz -Microsoft bestätigt, behebt aber nicht

    Tags:
    Cedric Gebistorf
    RSS Facebook LinkedIn
    DEFEND~1

    Blogbeitrag anhören

    0:00 / 0:00

    Kurzfassung

    Ein Kunde erhielt gezielt Phishing-Mails mit einem HTML-Dokument im Anhang. Als Sofortmassnahme blockierte unser Security Operations Center (SOC) die darin enthaltenen Domains mithilfe der Microsoft Defender for Endpoint (MDE) Network Protection.


    Die anschliessende Analyse des Vorfalls ergab, dass es zu keiner Kompromittierung gekommen war und keine Anmeldedaten abgeflossen sind. Um jedoch die Funktionsweise des Anhangs besser zu verstehen und zukünftige Angriffe effizienter abwehren zu können, wurde das HTML-Dokument trotzdem genauer untersucht. Dabei zeigte sich eine kritische Schwachstelle: Trotz aktivierter Network Protection konnten die im Anhang referenzierten, zuvor blockierten URLs weiterhin geladen werden.

    Dieser Befund wurde im Rahmen einer Responsible Disclosure an Microsoft gemeldet. Microsoft bestätigte die Lücke, kündigte jedoch an, sie nicht zu schliessen.
    Tags:

    Technische Details der Schwachstelle

    Voraussetzungen

    Die Schwachstelle betrifft Windows-Umgebungen mit Microsoft Edge. Getestet wurde unter anderem mit:

    • Windows 11 Enterprise (10.0.22631)
    • Edge Version 140.0.3485.54
    • Defender Client Version 4.18.25070.5
    • Modulversion 1.1.25070.4

    Funktionsweise von Network Protection

    Microsoft Defender Network Protection erweitert den klassischen Virenschutz, indem es Verbindungen zu gefährlichen oder potenziell schädlichen Domains und IP-Adressen blockiert. Dadurch sollen Phishing-Webseiten, Schad-software oder Command-and-Control-Kommunikation erkannt und verhindert werden. Neben den von Microsoft zentral verwalteten Blocklisten können Administratoren eigene Indikatoren im Defender Security Portal hinterlegen [1]. In der Praxis bedeutet dies, dass blockierte URLs in Edge nicht mehr aufrufbar sind, wie in Abbildung 1 dargestellt.

    Defender Network Protection blockiert den Zugang zu einer Webseite

    Abbildung: Defender Network Protection blockiert den Zugang zu einer Webseite

    Die Schwachstelle

    Öffnet ein Nutzer in Edge ein lokales HTML-Dokument, das in einem <script>-Tag eine blockierte URL referenziert (Beispiel-Code in Abbildung 2), wird der Inhalt dieser URL trotz aktiver Network Protection geladen (siehe Abbildung 3). Die Schutzfunktion greift in diesem Szenario nicht.

    Beispiel-Code eines lokalen HTML Files, welches die Network Protection umgeht.

    Abbildung: Beispiel-Code eines lokalen HTML Files, welches die Network Protection umgeht.

    Microsoft Edge lädt den Inhalt einer blockierten URL trotz aktiver Network Protection.

    Abbildung: Microsoft Edge lädt den Inhalt einer blockierten URL trotz aktiver Network Protection.

    Auswirkungen

    Die entdeckte Schwachstelle eröffnet Angreifern einen besonders attraktiven Vektor für Phishing-Kampagnen. Während Network Protection eigentlich dafür sorgen soll, dass der Aufruf bösartiger oder verdächtiger Domains zuverlässig blockiert wird, können Angreifer diese Sperren mithilfe von lokal geöffneten HTML-Anhängen gezielt umgehen.

    Damit ergeben sich mehrere Risiken:

    • Phishing-Szenarien: Angreifer versenden HTML-Anhänge, die beim Öffnen externe Skripte oder Inhalte nachladen. Nutzer sehen dabei eine täuschend echte Anmeldeseite oder ein manipuliertes Formular, das zur Eingabe von Zugangsdaten verleitet.
    • Umgehung von Sicherheitskontrollen: Da der Schadcode nicht direkt im Anhang enthalten ist, sondern dynamisch nachgeladen wird, greifen gängige Antivirenlösungen und E-Mail-Gateways oft nicht. Das erschwert sowohl die Prävention als auch die forensische Analyse.
    • Tarnung der Infrastruktur: Da die initialen Anhänge harmlos erscheinen, können Angreifer flexible und schwer erkennbar wechselnde Infrastruktur nutzen, indem sie den Schadcode erst im Nachgang aus externen Quellen bereitstellen.

    Insgesamt bedeutet dies, dass selbst in Umgebungen mit aktivierter Network Protection ein relevanter Angriffsvektor offenbleibt, der für zielgerichtete Attacken (z. B. Spear-Phishing gegen Unternehmen) missbraucht werden kann.

    Mitigations / Blue-Team Empfehlungen

    Microsoft hat die Schwachstelle bestätigt und spezifisch darauf hingewiesen, dass die derzeitige Integration von Network Protection in Edge den Nachteil aufweist, dass nur Frames und Subframes überprüft werden, nicht jedoch Subressourcen. Sie haben zudem angekündigt, die Schwachstelle vorerst nicht zu schliessen. Spezifisch erhielten wir die Antwort: "Nach sorgfältiger Prüfung erfüllt dieser Fall nicht die aktuellen Kriterien […] für eine sofortige Behebung. Wir werden jedoch eine Änderung des Designs in Betracht ziehen, um diesem Szenario in Zukunft Rechnung zu tragen."

    Das macht es umso wichtiger, dass Unternehmen eigene Massnahmen zur Risikominderung ergreifen.

    Folgende Empfehlungen können helfen, das Risiko zu reduzieren:

    Blockieren oder Quarantänisieren von E-Mails mit HTML-Anhängen (z. B. durch entsprechende Transport-Regeln oder Policies im Mail-Gateway).

    Schulung der Mitarbeitenden, HTML-Anhänge grundsätzlich als potenziell gefährlich zu betrachten.

    Überwachung mittels EDR-/XDR-Lösungen von Netzwerkzugriffen auf verdächtige externe Ressourcen, auch wenn diese nicht automatisch blockiert werden.

    Weitere Beobachtungen

    Während der Analyse fiel zudem auf, dass Defender Network Protection nicht in allen Szenarien greift. Insbesondere in Nicht-Edge-Browsern kann die Schutzfunktion umgangen werden, wenn moderne Protokolle wie Encrypted Client Hello (ECH) oder QUIC aktiv sind. Dies wird auch in der offiziellen Microsoft Dokumentation erwähnt [2]. In diesen Fällen werden blockierte Domains weiterhin erreicht, ohne dass eine Sperrung erfolgt.

    Dies zeigt, dass die Wirksamkeit von Network Protection stark vom eingesetzten Browser und dessen Protokollen abhängt. Administrator:innen sollten daher prüfen, ob ECH und QUIC in ihrer Umgebung deaktiviert werden können und Network Protection nicht als alleinige Verteidigungsschicht betrachten.

    Responsible Disclosure - Verantwortungsvolle Offenlegung

    Nach dem Fund der Schwachstelle kontaktierten wir Microsoft im Rahmen einer Responsible-Disclosure-Initiative.

    Erstmeldung: Die Schwachstelle wurde am 10.06.2025 detailliert beschrieben und mit reproduzierbarem Proof-of-Concept gemeldet.

    Microsofts Reaktion: Das Unternehmen bestätigte am 15.07.2025 die Lücke offiziell, stufte sie jedoch nicht als sicherheitsrelevant genug ein, um einen Fix zu veröffentlichen. Begründung: Angreifer hätten auch andere Möglichkeiten, vergleichbare Angriffe durchzuführen.

    90-Tage-Frist: Nach Ablauf der üblichen 90 Tage veröffentlichen wir diesen Bericht, um Transparenz zu schaffen. Organisationen sollen über das Risiko informiert sein und eigene Massnahmen treffen können.

    Wir möchten betonen, dass wir uns bei der Veröffentlichung an gängige Responsible-Disclosure-Praktiken halten. Die Entscheidung von Microsoft, diese Lücke nicht zu schliessen, sehen wir kritisch, insbesondere, da es sich um eine systematische Umgehung einer beworbenen Schutzfunktion handelt. Für Unternehmen entsteht dadurch eine falsche Sicherheit. Sie gehen davon aus, dass Network Protection alle definierten Regeln durchsetzt, was in der Praxis nicht gewährleistet ist.

    Quellen:

    [1] https://security.microsoft.com/securitysettings/endpoints/custom_ti_indicators

    [2] https://learn.microsoft.com/en-us/defender-endpoint/network-protection#known-issues--limitations