IT-Consulting Blog

Eine aktuelle Sicherheitsanalyse zu Microsoft Edge zeigt sehr deutlich, warum ich seit Jahren davor warne, Browser in Unternehmensumgebungen ungehärtet zu betreiben.

Der konkrete Vorwurf ist brisant: Microsoft Edge soll gespeicherte Passwörter bereits beim Start des Browsers vollständig in den Prozessspeicher laden und dort im Klartext vorhalten. Nicht erst dann, wenn der Benutzer die passende Webseite besucht. Nicht erst dann, wenn ein Login-Formular automatisch ausgefüllt wird. Sondern direkt nach dem Start des Browsers.

Damit entsteht ein dauerhaftes Ziel im Arbeitsspeicher.

Besonders kritisch: Zu der Analyse wurde auch ein Proof-of-Concept veröffentlicht. Dieses Tool, in Berichten unter anderem als EdgeSavedPasswordsDumper beschrieben, demonstriert, dass gespeicherte Zugangsdaten aus laufenden Edge-Prozessen ausgelesen werden können, wenn ein Angreifer den Prozessspeicher lesen darf. Laut Berichten wurde in einer Demonstration gezeigt, dass auf einem gemeinsam genutzten System sogar Zugangsdaten aus mehreren angemeldeten beziehungsweise getrennten Benutzersitzungen extrahiert werden konnten.

Und genau hier wird aus einer technischen Designentscheidung ein echtes Unternehmensrisiko.

Worum geht es bei der aktuellen Schwachstelle?

Browser-Passwortmanager speichern Zugangsdaten normalerweise verschlüsselt auf dem Datenträger. Das klingt zunächst beruhigend. Viele Benutzer gehen deshalb davon aus, dass ihre gespeicherten Passwörter sicher sind.

Das Problem liegt aber nicht nur auf der Festplatte.

Das Problem liegt zur Laufzeit.

Wenn Microsoft Edge beim Start alle gespeicherten Zugangsdaten entschlüsselt und im Klartext im Arbeitsspeicher des Browserprozesses vorhält, dann hilft die Verschlüsselung auf dem Datenträger im konkreten Angriffsszenario nur noch begrenzt. Denn der Angreifer muss dann nicht zwingend die Passwortdatenbank sauber entschlüsseln. Er kann versuchen, den laufenden Prozessspeicher auszulesen.

Genau dieses Verhalten wurde nun öffentlich thematisiert. Laut Cybersecurity News lädt Edge die gespeicherten Passwörter beim Browserstart in den Prozessspeicher und hält sie dort im Klartext vor — unabhängig davon, ob die jeweilige Webseite überhaupt verwendet wird. Heise beschreibt ebenfalls einen einfachen Test: Passwort im Edge-Passwortmanager gespeichert, Browser neu gestartet, Speicherabbild erzeugt, Klartext-Passwort im Dump gefunden.

Das ist aus Unternehmenssicht kein Detailproblem. Das ist genau die Art von Verhalten, die Angreifer lieben.

Die EXE macht das Risiko greifbar

Der veröffentlichte Proof-of-Concept ist deshalb so relevant, weil er das Problem aus der Theorie in die Praxis holt.

Solange über „Passwörter im Arbeitsspeicher“ gesprochen wird, klingt das für viele Entscheider abstrakt. Sobald aber eine ausführbare Datei beziehungsweise ein Demonstrationswerkzeug zeigt, dass gespeicherte Zugangsdaten aus laufenden Edge-Prozessen extrahiert werden können, wird das Risiko greifbar.

Wichtig ist dabei: Ein solches Tool ist nicht automatisch ein magischer Generalschlüssel. Ein Angreifer benötigt passende Rechte und Zugriff auf das System beziehungsweise auf die relevanten Prozesse. Aber genau das ist in realen Angriffsketten kein unrealistisches Szenario.

Nach einer erfolgreichen Kompromittierung suchen Angreifer fast immer nach Zugangsdaten. Credential Dumping ist ein Standardziel in Post-Exploitation-Szenarien. Passwörter, Tokens, Cookies, Sessions und Browserdaten sind für Angreifer extrem wertvoll, weil sie laterale Bewegung, Cloud-Zugriffe und Zugriff auf Fachanwendungen ermöglichen.

Wenn der Browser gespeicherte Kennwörter bereits im Klartext im Speicher bereithält, wird dem Angreifer die Arbeit erleichtert.

„By Design“ ist kein Freifahrtschein

Microsoft soll das Verhalten als „by design“ eingeordnet haben. Auch Microsofts eigene Dokumentation zu Browser-Sicherheit und Richtlinien macht deutlich, dass Browser über zentrale Policies in Unternehmen gesteuert werden können und sollten.

Das Argument „by design“ ist technisch nicht automatisch falsch. Hersteller definieren Threat Models. Häufig gilt: Wenn ein Angreifer bereits im lokalen Benutzerkontext oder mit administrativen Rechten auf dem System aktiv ist, liegt das Problem außerhalb des engeren Browser-Sicherheitsmodells.

Für die Praxis reicht diese Sichtweise aber nicht.

Professionelle IT-Sicherheit besteht aus mehreren Schutzschichten. Wenn ein Angreifer eine Schicht überwindet, darf nicht automatisch alles offenliegen. Genau deshalb gibt es Least Privilege, Applikationskontrolle, MFA, Conditional Access, Privileged Access Workstations, Credential Guard, EDR, Monitoring und Netzwerksegmentierung.

Ein integrierter Browser-Kennwortmanager, der alle gespeicherten Passwörter komfortabel im Speicher verfügbar hält, passt in vielen Unternehmensszenarien nicht zu diesem Schutzgedanken.

Er reduziert Reibung für Benutzer.

Leider reduziert er auch Reibung für Angreifer.

Die Re-Authentifizierung täuscht Sicherheit vor

Viele Benutzer kennen die Funktion: Wenn gespeicherte Passwörter im Browser angezeigt werden sollen, verlangt Edge eine erneute Authentifizierung, zum Beispiel über Windows Hello oder eine Windows-Anmeldung.

Das sieht sicher aus.

Aber genau hier liegt der Widerspruch.

Wenn die Zugangsdaten bereits im Klartext im Prozessspeicher liegen, schützt diese Abfrage in erster Linie die Oberfläche des Passwortmanagers. Sie verhindert nicht automatisch, dass ein Angreifer mit passenden Rechten den Speicher des Browserprozesses ausliest.

Die Benutzeroberfläche sagt: „Du musst dich erneut authentifizieren.“

Der Prozessspeicher sagt im schlechtesten Fall: „Die Daten sind bereits da.“

Das ist ein gefährlicher Unterschied zwischen gefühlter Sicherheit und tatsächlicher Schutzwirkung.

Terminalserver, RDS und Citrix: Der Jackpot für Angreifer

Besonders kritisch wird das Thema in geteilten Umgebungen wie Terminalservern, Remote Desktop Services, Citrix-Systemen oder anderen Multi-User-Plattformen.

Dort arbeiten mehrere Benutzer auf derselben Maschine oder Plattform. Es laufen mehrere Sitzungen, mehrere Browserprozesse, mehrere Benutzerprofile und häufig Zugriffe auf zentrale Fachanwendungen, Cloud-Portale, Kundensysteme oder Administrationsoberflächen.

Wenn in einer solchen Umgebung Browser-Kennwortmanager erlaubt sind, entsteht ein hochattraktives Ziel.

Für einen Angreifer ist das ein Jackpot.

Ein kompromittierter Terminalserver ist ohnehin ein schwerwiegender Vorfall. Wenn dort aber zusätzlich gespeicherte Browser-Passwörter im Klartext im Speicher laufender Prozesse verfügbar sind, kann aus einem einzelnen kompromittierten System eine Sammelstelle für Zugangsdaten werden.

Besonders gefährlich sind getrennte, aber weiterhin aktive Sitzungen. Benutzer melden sich oft nicht sauber ab, sondern trennen nur die Verbindung. Der Prozess läuft weiter. Der Browser bleibt geöffnet oder wird später wiederhergestellt. Die Sitzung bleibt ein lohnendes Ziel.

In solchen Umgebungen darf es aus meiner Sicht keine Diskussion geben:

Integrierte Browser-Kennwortmanager gehören auf Terminalservern, RDS-Hosts, Citrix-Systemen und VDI-Umgebungen deaktiviert.

Das eigentliche Problem ist größer als Microsoft Edge

Auch wenn die aktuelle Meldung Microsoft Edge betrifft, wäre es falsch, das Thema nur auf einen einzelnen Browser zu reduzieren.

Das eigentliche Problem ist grundsätzlicher: Viele Unternehmen behandeln Browser noch immer nicht als sicherheitskritische Anwendung.

Dabei ist der Browser heute der zentrale Zugangspunkt zu:

• Microsoft 365
• Entra ID
• Azure-Portalen
• CRM-Systemen
• ERP-Anwendungen
• Helpdesk-Systemen
• Cloud-Speichern
• Banking-Portalen
• internen Webanwendungen
• Administrationsoberflächen
• Kundensystemen

Wer den Browser kompromittiert oder dort gespeicherte Zugangsdaten auslesen kann, braucht oft keinen klassischen Domain-Admin mehr. Der Zugriff erfolgt dann direkt über legitime Webportale.

Deshalb sage ich seit Jahren: Browser dürfen in Unternehmensumgebungen nicht ungehärtet betrieben werden.

Und zur Härtung gehört ganz klar die Deaktivierung der integrierten Kennwortmanager.

Was Unternehmen jetzt konkret tun müssen

Die richtige Reaktion ist nicht, abzuwarten, ob Microsoft das Verhalten irgendwann ändert.

Die richtige Reaktion ist, die eigene Umgebung sofort zu prüfen und Browser-Härtung verbindlich umzusetzen.

1. Browser-Passwortmanager sofort prüfen

Unternehmen sollten kurzfristig prüfen:

• Ist der Edge-Passwortmanager aktiv?
• Können Benutzer Passwörter im Browser speichern?
• Gibt es gespeicherte Passwörter in bestehenden Profilen?
• Ist Autofill für Zugangsdaten aktiv?
• Werden Passwörter über Browserprofile synchronisiert?
• Gilt das auch auf Terminalservern, RDS, Citrix oder VDI?
• Gibt es unterschiedliche Regeln für Clients, Server und Admin-Systeme?

Gerade auf Terminalservern sollte diese Prüfung höchste Priorität haben.

2. Speichern von Passwörtern im Browser deaktivieren

Der integrierte Passwortmanager sollte in Unternehmensumgebungen per Richtlinie deaktiviert werden.

Für Microsoft Edge lässt sich das zentral über Gruppenrichtlinien, Intune, MDM oder andere Managementsysteme steuern. Microsoft stellt dafür umfangreiche Browser-Policies bereit, mit denen Unternehmen das Verhalten von Edge zentral konfigurieren können.

Wichtig ist: Es reicht nicht, Benutzer zu bitten, keine Passwörter zu speichern.

Das muss technisch verhindert werden.

3. Bereits gespeicherte Passwörter entfernen

Wenn der Passwortmanager deaktiviert wird, sollte zusätzlich geprüft werden, ob bereits gespeicherte Zugangsdaten in vorhandenen Browserprofilen liegen.

Sonst bleibt ein Altbestand bestehen, der weiterhin ein Risiko darstellen kann.

Hier braucht es ein sauberes Vorgehen:

• Bestandsaufnahme
• Kommunikation an Benutzer
• Migration in einen Enterprise-Passwortmanager
• Entfernung gespeicherter Browser-Passwörter
• technische Sperre gegen erneutes Speichern

Gerade dieser Punkt wird in der Praxis häufig vergessen. Eine Policy für die Zukunft ist gut. Aber sie löst nicht automatisch das Problem bereits gespeicherter Zugangsdaten.

4. Enterprise-Passwortmanager einsetzen

Wenn Benutzer viele Passwörter verwalten müssen, braucht es eine dafür geeignete Lösung.

Ein Enterprise-Passwortmanager sollte mindestens bieten:

• zentrale Verwaltung
• MFA
• Rollen- und Rechtekonzept
• Auditierung
• sicheres Teilen von Zugangsdaten
• Offboarding-Prozesse
• Richtlinien für Passwortqualität
• Zugriffskontrolle
• Trennung privater und geschäftlicher Zugangsdaten

Ein Browser-Passwortmanager ist kein Ersatz für ein professionelles Passwortmanagement.

5. Autofill restriktiv behandeln

Autofill ist bequem, aber ebenfalls kritisch. Automatisch ausgefüllte Zugangsdaten können missbraucht werden, insbesondere bei Phishing, manipulierten Formularen oder kompromittierten Webseiten.

In sensiblen Bereichen sollte Autofill deaktiviert oder stark eingeschränkt werden.

Das gilt besonders für:

• Admin-Portale
• Cloud-Management
• Banking
• Kundensysteme
• Fachanwendungen mit sensiblen Daten
• Terminalserver
• gemeinsam genutzte Arbeitsplätze

6. Browser-Synchronisation kontrollieren

Browser-Synchronisation kann ein weiteres Risiko sein.

Wenn Passwörter, Favoriten, Erweiterungen, Formulardaten und Einstellungen über private Konten oder unkontrollierte Profile synchronisiert werden, verliert die Organisation die Kontrolle über geschäftliche Daten.

Deshalb sollten Unternehmen klar regeln:

• Welche Konten dürfen im Browser angemeldet werden?
• Ist private Synchronisation erlaubt?
• Welche Daten dürfen synchronisiert werden?
• Sind geschäftliche Profile verpflichtend?
• Werden private Microsoft- oder Google-Konten blockiert?

Private Browser-Synchronisation hat auf Unternehmenssystemen nichts verloren.

7. Erweiterungen zentral verwalten

Browser-Erweiterungen sind eine massive Angriffsfläche.

Sie können Webseiteninhalte lesen, Formulare beeinflussen, Daten übertragen, Sitzungen manipulieren oder Benutzerverhalten auswerten. Deshalb sollten Erweiterungen nicht frei installierbar sein.

Empfehlung:

• Allowlist statt freier Installation
• Blocklist für bekannte Risiken
• regelmäßige Prüfung installierter Erweiterungen
• getrennte Regeln für Standardbenutzer und Administratoren
• keine privaten Erweiterungen auf Unternehmenssystemen

8. Terminalserver und RDS besonders absichern

Für Terminalserver, RDS, Citrix und VDI müssen strengere Regeln gelten als für normale Clients.

Dort sollten mindestens umgesetzt werden:

• Browser-Passwortmanager deaktivieren
• Autofill deaktivieren oder einschränken
• Browser-Synchronisation deaktivieren
• private Konten blockieren
• Erweiterungen zentral verwalten
• Sitzungen sauber beenden
• getrennte Profile kontrollieren
• lokale Administratorrechte stark begrenzen
• Monitoring auf verdächtige Prozesszugriffe
• EDR-Regeln für Credential-Dumping-Verhalten
• regelmäßige Bereinigung alter Profile

Ein Terminalserver ist kein normaler Arbeitsplatz. Er ist ein Konzentrator von Risiko.

9. Admin-Zugriffe vom Alltag trennen

Administrative Tätigkeiten gehören nicht in denselben Browserkontext wie normales Arbeiten.

Admin-Portale sollten über getrennte, gehärtete Umgebungen genutzt werden:

• separate Admin-Konten
• separate Browserprofile
• Privileged Access Workstations
• Conditional Access
• MFA
• keine Passwortspeicherung
• keine privaten Erweiterungen
• keine parallele Alltagsnutzung

Wer mit demselben Browser gleichzeitig Mails liest, Webseiten besucht und Admin-Portale öffnet, schafft unnötige Angriffsfläche.

10. Browser-Härtung regelmäßig überprüfen

Browser ändern sich ständig. Neue Funktionen kommen hinzu. Richtlinien ändern sich. Hersteller passen Standardverhalten an. Neue Synchronisations-, KI- oder Komfortfunktionen werden aktiviert.

Deshalb reicht es nicht, Browser-Härtung einmal einzurichten und dann jahrelang nicht mehr anzufassen.

Browser-Policies gehören regelmäßig geprüft.

Mindestens bei:

• neuen Browser-Versionen
• neuen Unternehmensanforderungen
• Einführung von M365-/Cloud-Diensten
• RDS-/VDI-Projekten
• Security-Audits
• Kunden- oder Compliance-Anforderungen
• bekannten Schwachstellen oder neuen PoCs

Die falsche Frage: „Ist das wirklich eine Schwachstelle?“

In Diskussionen zu solchen Themen kommt oft schnell die Frage auf, ob es sich im engeren Sinne um eine Schwachstelle handelt.

Diese Frage ist für die Praxis zweitrangig.

Die bessere Frage lautet:

Will ich als Unternehmen, dass gespeicherte Unternehmenspasswörter in Browserprofilen und laufenden Browserprozessen verfügbar sind?

Meine Antwort ist klar: Nein.

Gerade in professionellen IT-Umgebungen darf man sich nicht auf Standardkonfigurationen verlassen. Standards sind auf breite Nutzbarkeit ausgelegt. Nicht auf das höchste Sicherheitsniveau für jede Unternehmensumgebung.

Für private Benutzer mag ein integrierter Browser-Kennwortmanager ein akzeptabler Komfortkompromiss sein. Für Unternehmensumgebungen, Terminalserver, Administratoren und geteilte Systeme ist dieser Kompromiss aus meiner Sicht nicht tragbar.

Fazit: Die aktuelle Edge-Schwachstelle ist ein Weckruf

Die aktuelle Diskussion um Microsoft Edge zeigt sehr deutlich, was ich seit Jahren sage:

Browser sind keine harmlose Standardsoftware mehr.

Sie sind zentrale Zugangspunkte zu Unternehmensdaten, Cloud-Diensten, Fachanwendungen und Administrationsoberflächen. Wer Browser nicht härtet, lässt eine der wichtigsten Anwendungen im Unternehmen weitgehend unkontrolliert.

Die veröffentlichte EXE beziehungsweise der Proof-of-Concept macht das Risiko greifbar: Gespeicherte Passwörter im Browser sind nicht nur ein theoretisches Problem. Sie können im falschen Szenario zu einem direkten Ziel für Credential Dumping werden.

Besonders auf Terminalservern, RDS-, Citrix- und VDI-Systemen ist das brandgefährlich.

Deshalb müssen Unternehmen jetzt handeln:

Browser-Passwortmanager deaktivieren. Bereits gespeicherte Passwörter entfernen. Enterprise-Passwortmanager einsetzen. Browser zentral härten. Terminalserver gesondert absichern. Admin-Zugriffe trennen.

Bequemlichkeit darf nicht über Sicherheit stehen.

Der Browser ist heute nicht mehr nur ein Werkzeug zum Surfen.

Er ist ein sicherheitskritischer Zugangspunkt zum Unternehmen.

Und genau so muss er behandelt werden.

Im Juli 2026 führt Microsoft eine Änderung in Exchange Online ein, die auf den ersten Blick wie eine kleine DNS-Anpassung wirkt, tatsächlich aber ein wichtiger Schritt für eine stärkere Sicherheitsarchitektur im E-Mail-Transport ist.

Bei neuen akzeptierten Domains werden MX-Records künftig nicht mehr unter
*.mail.protection.outlook.com
bereitgestellt, sondern unter
*.mx.microsoft.

Diese Änderung schafft die Grundlage für eine saubere DNSSEC-Vertrauenskette und eine bessere Unterstützung von SMTP DANE, wodurch die Sicherheit beim Versand von E-Mails deutlich verbessert werden kann.

---

Warum diese Änderung wichtig ist

Die Anpassung betrifft nicht das Routing von E-Mails, sondern die zugrunde liegende Sicherheitsarchitektur.
Der bisherige MX-Namespace erschwerte es, eine durchgängige DNSSEC-Trust-Chain bis in die Microsoft-Mailinfrastruktur aufzubauen.

Mit dem neuen Namespace kann Microsoft künftig:

• MX-Endpunkte besser mit DNSSEC-fähiger Infrastruktur verknüpfen
• TLSA-Records für SMTP DANE sauber bereitstellen
• die Identität von Mailservern während der TLS-Verhandlung zuverlässiger prüfen

Das Ziel ist eine stärkere Absicherung der Transportverschlüsselung zwischen Mailservern.

---

Hintergrund: TLS ohne verpflichtende Validierung reicht nicht mehr aus

Der überwiegende Teil des E-Mail-Verkehrs im Internet verwendet weiterhin TLS ohne verpflichtende Servervalidierung.
Dabei wird die Verbindung zwar verschlüsselt, aber das Zielsystem wird nicht streng authentifiziert.

Das eröffnet theoretisch Angriffsflächen, zum Beispiel durch:

• DNS-Manipulation
• Downgrade-Angriffe
• Man-in-the-Middle-Angriffe
• kompromittierte Zertifikate

Hier setzen DNSSEC und SMTP DANE an.

DNSSEC

• signiert DNS-Antworten kryptografisch
• verhindert DNS-Spoofing
• stellt sicher, dass MX-Einträge authentisch sind

SMTP DANE

• veröffentlicht TLS-Informationen über DNS (TLSA-Records)
• nutzt DNSSEC zur Absicherung
• stellt sicher, dass Mailserver nur mit verifizierter Infrastruktur kommunizieren
• verhindert TLS-Downgrades und Man-in-the-Middle-Angriffe

Der neue Namespace mx.microsoft erleichtert es Microsoft, eine vollständige DNSSEC-Trust-Chain bis zu Exchange Online aufzubauen und damit eine stärkere Validierung des Mailtransports zu ermöglichen.

---

Was Administratoren jetzt tun sollten

Für die meisten Tenants ist keine sofortige Aktion erforderlich.
Die Änderung betrifft zunächst nur neu hinzugefügte akzeptierte Domains.

Trotzdem ist dies ein guter Zeitpunkt, die eigene Mail-Security zu überprüfen.

Empfohlene Checks

• Prüfen, ob die eigene DNS-Zone mit DNSSEC signiert ist
• Sicherstellen, dass Skripte oder Automatisierungen kein festes MX-Format erwarten
• Mail-Transport mit DNSSEC- / DANE-Testtools überprüfen
• Monitoring für MX- und TLS-Validierung aktivieren

---

Wichtiger Hinweis

Bestehende Domains sollten durch diese Änderung nicht beeinträchtigt werden.
Probleme können jedoch auftreten, wenn Umgebungen auf hart codierte MX-Hostnamen, Validierungsregeln oder alte Automatisierungsskripte angewiesen sind.

Gerade in größeren oder stark automatisierten Microsoft-365-Umgebungen empfiehlt es sich daher, die Kompatibilität frühzeitig zu prüfen.

---

Fazit

Die Umstellung auf *.mx.microsoft ist keine kosmetische Änderung, sondern ein strategischer Schritt hin zu:

• stärkerer Transportverschlüsselung
• verifizierbaren Mailserver-Identitäten
• besserer DNSSEC-Integration
• breiterer Unterstützung von SMTP DANE

Damit schafft Microsoft eine wichtige Grundlage für einen deutlich sichereren E-Mail-Transport im Microsoft-365-Ökosystem.

Einleitung

Zwischen „TLS wird schon irgendwie genutzt“ und wirklich belastbarer Transportsicherheit liegt im Mailflow ein großer Unterschied. Genau in dieser Lücke bewegen sich SMTP DANE und MTA-STS. Microsoft hat am 10. März 2026 angekündigt, dass sich diese Sicherheitsmechanismen in Exchange Online nun auch gezielt über Outbound Connectors steuern lassen. Das ist vor allem für Partnerstrecken, Smart-Host-Szenarien und regulierte Kommunikationspfade relevant.

Wichtig ist die Einordnung: SMTP DANE mit DNSSEC und MTA-STS sind im ausgehenden Pfad von Exchange Online bereits standardmäßig aktiv. Neu ist nicht die generelle Existenz der Protokolle, sondern die Möglichkeit, ihr Verhalten pro Outbound Connector bewusster zu steuern. Damit wird aus einer Plattformfunktion ein Architektur- und Betriebshebel für konkrete Routing-Szenarien.

Was bedeutet das?

Die neue Konstellation betrifft vor allem Organisationen, die E-Mails nicht ausschließlich über den Standardpfad von Exchange Online zustellen. Sobald domänenspezifische Outbound Connectors, Partner-Connectoren oder Smart Hosts im Spiel sind, entsteht die Frage, wie strikt Exchange Online die Transportabsicherung auf genau diesen Routen prüfen soll. Genau dafür sind die neuen Connector Modes gedacht.

Für die Praxis heißt das: Sicherheitsvorgaben lassen sich besser an den jeweiligen Kommunikationspfad anpassen. Gleichzeitig steigt die Verantwortung in Design und Betrieb, denn ein zu lockerer Modus reduziert die Schutzwirkung, während ein zu strenger Modus zu Warteschlangen, NDRs und im Fehlerfall zu verworfenen Nachrichten führen kann.

Was ist SMTP DANE?

SMTP DANE erweitert den SMTP-Transport um eine kryptografisch abgesicherte Vertrauenskette auf Basis von DNSSEC und TLSA-Records. Vereinfacht gesagt prüft der sendende Server nicht nur, ob TLS möglich ist, sondern auch, ob der angesprochene Zielserver tatsächlich der erwartete Mailserver für die Domain ist und ob dessen Zertifikat zu den veröffentlichten TLSA-Informationen passt. Damit wird ein Teil des Risikos adressiert, das bei rein opportunistischem TLS durch DNS-Manipulation oder Man-in-the-Middle-Angriffe bestehen bleibt.

Wenn für eine Ziel-Domain kein TLSA-Record vorhanden ist, läuft der Mailflow grundsätzlich ohne DANE-Prüfung weiter. Wenn die Domain jedoch DANE signalisiert und die DNSSEC- oder TLSA-Prüfung fehlschlägt, kann Exchange Online die Zustellung zurückstellen oder blockieren. Microsoft dokumentiert dafür unter anderem Fehlerbilder wie tlsa-invalid, dnssec-invalid, starttls-not-supported oder Zertifikat-Host-Mismatch.

Was ist MTA-STS?

MTA-STS verfolgt dasselbe Ziel wie DANE: den Schutz des SMTP-Transports gegen Downgrade- und Man-in-the-Middle-Angriffe. Technisch funktioniert es aber anders. Statt auf DNSSEC und TLSA zu setzen, veröffentlicht die Ziel-Domain per DNS-TXT-Eintrag einen Hinweis auf eine per HTTPS bereitgestellte Richtlinie. Diese Policy definiert, welche MX-Hosts erwartet werden, ob TLS erzwungen werden soll und wie lange die Richtlinie gecacht werden darf.

Für Exchange Online ist relevant, dass MTA-STS im ausgehenden Pfad Teil der Sicherheitsinfrastruktur ist. Bei Smart-Host-basierten Outbound Connectors prüft Exchange Online MTA-STS nicht gegen die finale Empfängerdomain, sondern gegen die Smart-Host-Domain. Das ist ein wichtiger Punkt, weil sich dadurch die Vertrauenskette an der tatsächlichen Routing-Architektur orientiert.

Der Unterschied zwischen SMTP DANE und MTA-STS

Beide Standards schließen Sicherheitslücken, die opportunistisches TLS allein nicht abdeckt. Der wesentliche Unterschied liegt im Vertrauensmodell: DANE stützt sich auf DNSSEC und TLSA, MTA-STS auf Zertifizierungsstellen sowie eine per HTTPS veröffentlichte Richtlinie. Microsoft beschreibt ausdrücklich, dass beide Protokolle demselben Zweck dienen, aber unterschiedliche technische Grundlagen nutzen.

Für Architekturentscheidungen ist das mehr als ein Protokolldetail. DANE ist besonders stark, wenn DNSSEC sauber betrieben wird. MTA-STS ist oft einfacher in bestehende Web- und Zertifikatsprozesse einzubetten. In hybriden oder partnerbezogenen Szenarien ist deshalb nicht nur wichtig, welches Protokoll sicherer wirkt, sondern welches entlang der gesamten Route sauber betrieben und dauerhaft überwacht werden kann. Diese Einordnung ist eine fachliche Schlussfolgerung auf Basis der von Microsoft beschriebenen Vertrauensmodelle und Betriebsanforderungen.

Was ist an den neuen Connector Modes in Exchange Online neu?

Für Outbound Connectors dokumentiert Microsoft jetzt zwei steuerbare Parameter: SmtpDaneMode und MtaStsMode. Für SMTP DANE sind die Werte Opportunistic, Mandatory und None verfügbar. Für MTA-STS sind die Werte Opportunistic und None dokumentiert. In beiden Fällen ist Opportunistic der Standardwert.

Bei SmtpDaneMode=Opportunistic nutzt Exchange Online DANE, wenn die Ziel-Domain DANE mit DNSSEC unterstützt. Wenn die Domain DANE nicht unterstützt, wird die Nachricht mit den Connector- oder Standard-Einstellungen zugestellt. Unterstützt die Domain DANE, aber die Validierung scheitert, stellt Exchange Online die Nachricht bis zu 24 Stunden zurück, versucht gegebenenfalls auf einen sekundären MX auszuweichen und verwirft die Nachricht anschließend, wenn die Validierung weiterhin fehlschlägt. Mit Mandatory wird DANE für diesen Connector zur Pflicht, also auch dann zum Zustellhindernis, wenn die Ziel-Domain DANE gar nicht anbietet.

Bei MtaStsMode=Opportunistic verhält sich Exchange Online ähnlich zurückhaltend, aber mit einer wichtigen Besonderheit: Es gibt hier keinen separaten Mandatory-Wert auf Connector-Ebene. Die harte Wirkung entsteht dann, wenn die Ziel-Domain selbst eine MTA-STS-Policy im Modus enforce veröffentlicht und die Validierung fehlschlägt. Dann wird die Nachricht bis zu 24 Stunden erneut versucht und anschließend verworfen. None deaktiviert die Prüfung, senkt laut Microsoft aber ausdrücklich die Sicherheit und kann Umleitungen oder Abfangen von Nachrichten begünstigen.

Genau diese Unterscheidung ist für die Beratung wichtig: SMTP DANE kann auf Connector-Ebene explizit verpflichtend gemacht werden. MTA-STS lässt sich auf Connector-Ebene dagegen nur opportunistisch nutzen oder abschalten. Wer beide Protokolle gedanklich gleich behandelt, übersieht einen entscheidenden Architekturunterschied.

Was sollte man beachten und tun?

Outbound Connectors zuerst fachlich klassifizieren

Nicht jeder Connector braucht dieselbe Strenge. Zuerst sollte klar sein, welche Connectoren sicherheitskritische Partnerkommunikation, regulierte Mailflows oder Smart-Host-Routen bedienen und welche nur technische Sonderwege abbilden. Erst danach ergibt eine Entscheidung über Opportunistic, Mandatory oder None fachlich Sinn. Die Dokumentation der Parameter zeigt, dass diese Entscheidung direkte Auswirkungen auf Zustellverhalten und Sicherheitsniveau hat.

None nur als bewusste Ausnahme behandeln

Microsoft weist bei None für beide Protokolle ausdrücklich auf reduzierte Sicherheit sowie das Risiko von Umleitung oder Abfangen durch bösartige Gegenstellen hin. Daraus folgt für Governance und Beratung: None sollte kein bequemer Standard sein, sondern eine dokumentierte Ausnahme mit klarer Begründung, etwa für temporäre Interoperabilitätsprobleme. Diese Empfehlung ist eine unmittelbare Ableitung aus Microsofts Risikobeschreibung.

Smart-Host-Szenarien sauber prüfen

Gerade bei Partner- oder Gateway-Routen ist die technische Realität oft komplexer als das Ziel-Domain-Modell. Für MTA-STS dokumentiert Microsoft ausdrücklich, dass bei Smart-Host-Connectoren gegen die Smart-Host-Domain validiert wird. Wer diesen Punkt im Design übersieht, bewertet Fehlermeldungen falsch oder setzt die falschen Erwartungen an die Gegenstelle.

Monitoring und Troubleshooting vorbereiten

Für den operativen Betrieb ist der Bericht Outbound messages in Transit Security relevant. Dort zeigt Exchange Online Daten zu DANE, MTA-STS, TLS-Only und No TLS sowie blockierte Nachrichten aufgrund von Validierungsfehlern. Ergänzend helfen NDR- und SMTP-Fehlercodes wie 5.4.8, 5.7.5, 4.7.323 oder 4.7.324, um zwischen Policy-, Zertifikats-, DNSSEC- und TLSA-Problemen zu unterscheiden.

Eigene Domains auf Eingangsseite sauber vorbereiten

Wer nicht nur ausgehend sicher senden, sondern auch eingehend geschützt empfangen will, sollte die eigene Domain-Konfiguration prüfen. Für MTA-STS beschreibt Microsoft die notwendige Kombination aus TXT-Record und HTTPS-Policy. Für DNSSEC- und DANE-bezogene Prüfungen stellt Exchange Online zudem das Cmdlet Get-DnssecStatusForVerifiedDomain bereit, das DNS-, MX- und MTA-STS-bezogene Validierungen für akzeptierte Domains sichtbar macht.

Fazit

Die Ankündigung zu SMTP DANE- und MTA-STS-Connector-Modes in Exchange Online ist kein kleines Transport-Detail, sondern eine relevante Erweiterung für alle Organisationen mit differenziertem Mailrouting. Der eigentliche Mehrwert liegt darin, Sicherheitsmechanismen nicht nur global hinzunehmen, sondern pro Connector bewusst in die Mailflow-Architektur einzubauen.

Wer Exchange Online mit Partner-Connectoren, Smart Hosts oder streng regulierten Kommunikationspfaden betreibt, sollte diese neuen Steuerungsmöglichkeiten jetzt in Designstandards, Betriebsdokumentation und Fehlerszenarien aufnehmen. Besonders wichtig ist dabei die saubere Trennung zwischen DANE und MTA-STS, weil beide zwar dasselbe Ziel verfolgen, in Exchange Online aber nicht identisch gesteuert werden.

Mit der Veröffentlichung der aktuellen Exchange Server Sicherheitsupdates macht Microsoft erneut deutlich, wie kritisch der sichere Betrieb von On-Premises-E-Mail-Systemen ist. Auch wenn aktuell keine aktiv ausgenutzten Angriffe gemeldet wurden, ist die Botschaft klar: Ungepatchte oder nicht mehr unterstützte Exchange-Server stellen ein erhebliches Risiko dar.

Für Unternehmen bedeutet das konkret:

Entweder Exchange Server Subscription Edition (SE) einsetzen – oder zwingend am ESU-Programm teilnehmen.

Alles andere ist aus Sicherheits- und Compliance-Sicht nicht mehr vertretbar.

Was bedeutet die aktuelle Sicherheitsupdate-Ankündigung?

Microsoft stellt Sicherheitsupdates inzwischen primär für Exchange Server Subscription Edition (SE) bereit.

Für Exchange Server 2016 und 2019 gilt:

• Sicherheitsupdates gibt es nur noch im Rahmen des kostenpflichtigen Extended Security Update (ESU) Programms
• Ohne ESU-Teilnahme erhalten diese Versionen keine weiteren Security Updates
• Das ESU-Programm ist zeitlich befristet und endet spätestens im April 2026

Damit ist klar: Exchange 2016/2019 befinden sich faktisch im End-of-Life-Betrieb – selbst wenn sie technisch noch laufen.

Warum Unternehmen längst auf Exchange SE umgestellt haben sollten

Als IT-Consultant sehe ich in Projekten immer wieder dieselbe Situation:

Exchange funktioniert „noch“, also wird das Thema Migration aufgeschoben. Genau das ist gefährlich.

1. Sicherheitsrisiko

Exchange war in den letzten Jahren regelmäßig Ziel großflächiger Angriffe. Ein ungepatchter Server ist kein isoliertes Risiko, sondern oft ein Einstiegspunkt ins gesamte Unternehmensnetzwerk.

2. Compliance & Audit-Fähigkeit

Viele Standards (ISO 27001, TISAX, NIS2, interne Audits) verlangen:

• Hersteller-Support
• zeitnahe Sicherheitsupdates
• dokumentierte Patch-Prozesse

Ein Exchange ohne Support oder ESU ist hier nicht mehr verteidigungsfähig.

3. Exchange SE ist der neue Standard

Microsoft hat die Richtung klar vorgegeben:

• Exchange Server SE ist die einzige On-Premises-Version mit langfristigem Update-Pfad
• Regelmäßige Sicherheitsupdates
• Planbare Wartung
• Keine Sonderprogramme oder Ausnahmen mehr nötig

Kurz gesagt: SE ist kein „Upgrade“, sondern der neue Normalzustand.

Was ist das ESU-Programm – und wann ist es sinnvoll?

Das Extended Security Update (ESU) Programm ist eine Übergangslösung für Unternehmen, die aus organisatorischen oder technischen Gründen noch nicht auf Exchange SE migriert sind.

Was ESU bietet:

• Sicherheitsupdates für Exchange 2016 / 2019
• Nur Critical und Important Vulnerabilities
• Keine Feature-Updates
• Kein regulärer Produktsupport

Was ESU nicht ist:

• Keine dauerhafte Lösung
• Kein Ersatz für eine Migration
• Keine Garantie auf monatliche Updates

ESU kauft Zeit – nicht Sicherheit auf Dauer.

Wie kann man das ESU-Programm erwerben?

Der Erwerb des ESU-Programms läuft nicht automatisiert, sondern über Microsoft bzw. Partner.

Voraussetzungen

• Exchange 2016: CU23
• Exchange 2019: CU14 oder CU15
• Sauberer, unterstützter Update-Stand

Ablauf in der Praxis

1. Microsoft Account Team oder Partner kontaktieren
   Falls kein eigenes Account Team vorhanden ist, übernimmt dies meist ein Microsoft-Partner.
2. ESU-Lizenz pro Exchange-Server erwerben
3. Zugriff auf private Security Updates erhalten
4. Patch-Prozess weiterhin aktiv betreiben

Wichtig:

Nach Ende der öffentlichen Updates werden ESU-Security-Updates nicht mehr frei verfügbar, sondern nur noch ESU-Kunden bereitgestellt.

Microsoft Entra ID unterstützt Conditional Access für Agent Identities. Überblick zu Konzept, Einsatzszenarien und Sicherheitsvorteilen.

Conditional Access für Agent Identities in Microsoft Entra ID

Mit der zunehmenden Nutzung von Automatisierung, Workflows und KI-gestützten Diensten steigt die Anzahl nicht-menschlicher Identitäten in Entra-ID-Umgebungen deutlich. Microsoft adressiert diese Entwicklung mit der Einführung von Conditional Access für sogenannte Agent Identities. Der Microsoft-Beitrag aus der Tech Community beschreibt, wie diese Identitäten abgesichert werden können und welche neuen Steuerungsmöglichkeiten sich daraus ergeben.

Was sind Agent Identities?

Agent Identities repräsentieren nicht-interaktive Akteure wie:

• KI-Agenten
  • Automatisierte Services
    • Hintergrundprozesse
• Orchestrierte Workflows

Im Gegensatz zu klassischen Benutzeridentitäten agieren sie eigenständig, oft dauerhaft und mit weitreichenden Berechtigungen. Genau daraus ergibt sich ein erhöhtes Sicherheitsrisiko, wenn Zugriffe nicht granular kontrolliert werden.

Sicherheitsproblem klassischer Service-Identitäten

Traditionell werden für nicht-menschliche Zugriffe Service Principals, Managed Identities oder App-Registrierungen verwendet. Diese Identitäten:

• Arbeiten häufig mit langlebigen Geheimnissen oder Zertifikaten
• Unterliegen nicht denselben Conditional-Access-Regeln wie Benutzer
• Entziehen sich kontextbasierter Zugriffskontrolle

Der Microsoft-Artikel ordnet Agent Identities als Weiterentwicklung ein, um diese Lücke zu schließen.

Conditional Access für Agent Identities – Konzept

Conditional Access für Agent Identities erweitert das bekannte CA-Modell um nicht-menschliche Identitäten. Dabei werden Zugriffsentscheidungen nicht mehr ausschließlich auf Benutzerkontexten getroffen, sondern auf Eigenschaften des Agenten und dessen Ausführungsumgebung.

Mögliche Steuerungsparameter sind unter anderem:

• Identität des Agenten
• Zielressource
• Risiko- und Kontextinformationen
• Mandanten- und Workload-Zugehörigkeit

Abgrenzung zu Benutzer-Conditional-Access

Ein zentrales Thema des Beitrags ist die klare Trennung zwischen Benutzer- und Agenten-Policies. Agent Identities benötigen eigene Richtlinien, da klassische Bedingungen wie Standort, Gerät oder MFA nicht anwendbar sind.

Microsoft verfolgt hier einen separaten Policy-Ansatz, um Fehlkonfigurationen und unbeabsichtigte Blockierungen produktiver Workloads zu vermeiden.

Typische Einsatzszenarien

Absicherung von KI- und Automatisierungsdiensten

Agent Identities eignen sich besonders für KI-basierte Dienste, die selbstständig auf APIs, Daten oder andere Cloud-Ressourcen zugreifen. Conditional Access ermöglicht hier eine gezielte Einschränkung auf notwendige Zielsysteme.

Zero-Trust-Architekturen für Workloads

Durch Conditional Access für Agenten lässt sich das Zero-Trust-Prinzip auch auf nicht-menschliche Identitäten anwenden. Jeder Zugriff wird explizit bewertet und autorisiert.

Reduktion von Seitwärtsbewegungen

Granulare CA-Regeln können verhindern, dass kompromittierte Agenten unkontrolliert auf weitere Ressourcen zugreifen.

Aktueller Stand und Einschränkungen

Der Microsoft-Beitrag macht deutlich, dass sich Conditional Access für Agent Identities noch in der Weiterentwicklung befindet. Nicht alle Szenarien und Dienste werden aktuell unterstützt. Organisationen sollten daher:

• Den unterstützten Funktionsumfang genau prüfen
• Bestehende Service-Identitäten evaluieren
• Pilotprojekte klar abgrenzen

Einordnung aus Beratungssicht

Conditional Access für Agent Identities ist ein wichtiger Schritt, um die Sicherheitslücke zwischen Benutzer- und Workload-Identitäten zu schließen. Der Ansatz zeigt, dass Microsoft die steigende Bedeutung autonomer Systeme in Entra ID strategisch adressiert.

Für produktive Umgebungen ist jedoch entscheidend, neue Richtlinien kontrolliert einzuführen und bestehende Automatisierungen nicht unbeabsichtigt zu beeinträchtigen.

Zusammenfassung

Der Microsoft-Tech-Community-Beitrag zeigt, wie Conditional Access gezielt auf Agent Identities angewendet werden kann. Damit lassen sich moderne Automatisierungs- und KI-Szenarien besser absichern, ohne auf klassische Benutzermechanismen zurückzugreifen. Für Unternehmen mit wachsender Anzahl nicht-menschlicher Identitäten ist dies ein relevanter Baustein moderner Entra-ID-Sicherheitsarchitekturen.

Mit seinem aktuellen Update kündigt Microsoft an, dass Security Copilot künftig ohne Zusatzkosten als Bestandteil der Microsoft 365 E5-Lizenz enthalten sein wird. Damit wird eine leistungsstarke KI-gestützte Sicherheitslösung direkt in die täglichen Arbeitsabläufe von Sicherheitsteams integriert. 

Überblick und Zeitpunkt

Die Integration startet ab dem 18. November 2025 für bestehende Kunden von Microsoft 365 E5, die Security Copilot bereits nutzen.  Im Anschluss erfolgt die sukzessive Ausrollung für alle Microsoft 365 E5-Kunden. Vor Aktivierung erhalten Kunden eine 30-Tage Vorankündigung. 

Lizenz- und Nutzungskapazitäten

• Für jeden 1.000 bezahlten Nutzerlizenzen im Rahmen von Microsoft 365 E5 werden monatlich 400 Security Compute Units (SCU) kostenfrei bereitgestellt, maximal bis zu 10.000 SCU pro Monat.  
• Beispiel: Ein Unternehmen mit 400 Nutzerlizenzen bekommt 160 SCU pro Monat. Bei 4.000 Nutzerlizenzen sind es 1.600 SCU pro Monat.  
• Nicht genutzte SCUs verfallen am Monatsende — ein Übertrag in spätere Monate erfolgt nicht.  

Was ist inbegriffen – und was nicht?

Inbegriffene Fähigkeiten:

• Zugriff auf die Kern-Erlebnisse von Security Copilot wie Chat- und Agent-Szenarien über Produkte wie Microsoft Defender, Microsoft Entra, Microsoft Intune und Microsoft Purview.  
• Möglichkeit, selbst (oder durch Partner) Agenten, Prompt-Bücher oder Integrationen zu entwickeln (z. B. über Agent Builder, APIs) innerhalb dieses Angebots.  

Nicht automatisch inbegriffen:

• Kosten für bestimmte Zusatzkomponenten wie z. B. Daten-Lake-Compute/Storage in Microsoft Sentinel, oder Lizenzen für Partner-Agenten über den Security Store.  
• Voraussetzungen außerhalb der Microsoft 365 E5 Lizenz, wenn erforderlich, sind nicht automatisch abgedeckt.  

Zugangs- und Einsatzbedingungen

• Jeder Microsoft 365 E5-Kunde ist für die Inklusion berechtigt – unabhängig von der Anzahl der Nutzerlizenzen.  
• Es ist keine zusätzliche Provisionierung von SCUs notwendig: Die Nutzung wird automatisch bereitgestellt, wenn das Angebot aktiviert wird.  
• Kunden ohne Microsoft 365 E5 können Security Copilot weiterhin über das bisherige Preismodell beziehen – die Inklusion ist nicht exklusiv und ersetzt nicht das eigenständige Angebot.  

Bedeutung für Unternehmen

Für Unternehmen bedeutet diese Entscheidung: Sicherheitsteams bekommen künftig mit minimalem administrativen Aufwand Zugriff auf fortschrittliche KI-Agenten, die in den bekannten Microsoft‐Sicherheitsprodukten arbeiten. Das senkt Einstiegshürden, erleichtert die Nutzung von Automatisierung im Sicherheitsbetrieb (z. B. bei Incident-Triage, Phishing-Bearbeitung, Zugriffskontrollen) und verbessert insgesamt die Reaktionsfähigkeit.

Gleichzeitig bleibt es wichtig, diese Kapazitäten sinnvoll zu steuern: Die verfügbar gemachten SCUs sind limitiert, nicht genutzte Einheiten verfallen, und bei Überschreitung können Zusatzkosten entstehen. Zudem muss das Unternehmen die Konfiguration von Agenten und Workflows aktiv angehen – die Technologie liefert das „Werkzeug“, nicht automatisch das „Fertigsystem“.

Fazit

Mit der Einbindung von Security Copilot in die Microsoft 365 E5-Lizenz setzt Microsoft einen klaren Impuls: Sicherheits-KI wird nicht mehr exklusives Premium-Tool, sondern Teil der Standard-Sicherheitsinfrastruktur im Unternehmenskontext. Das stärkt die Automatisierung und Effizienz von IT-Sicherheits- und Betriebsaufgaben. Für Berater und IT-Verantwortliche gilt: Jetzt gilt es, die Einführung zu planen – von Lizenzcheck über Kapazitäts-Monitoring bis hin zur organisatorischen Verankerung solcher Agenten-Workflows.

Microsoft hat angekündigt, das bislang separat erhältliche Sysinternals-Tool Sysmon (System Monitor) direkt in Windows 11 sowie Windows Server 2025 zu integrieren. Damit wird ein wichtiges Analyse- und Sicherheitswerkzeug künftig Bestandteil des Betriebssystems und muss nicht mehr manuell nachinstalliert werden.

Was ist Sysmon?

Sysmon ist ein Überwachungstool, das tiefgehende Informationen über Prozessstarts, Netzwerkverbindungen, Dateiänderungen und andere sicherheitsrelevante Systemaktivitäten erfasst. Diese Ereignisse werden im Windows-Eventlog protokolliert und dienen als Grundlage für Sicherheitsanalysen, Incident Response und forensische Untersuchungen.

Bisher war Sysmon ein optionales Tool aus der Sysinternals-Suite, das Unternehmen manuell verteilen und konfigurieren mussten.

Was ändert sich durch die neue Integration?

• Optionale Windows-Komponente
  Sysmon wird künftig als aktivierbare Funktion direkt im Betriebssystem vorhanden sein. Administratoren können es also ohne separaten Download einrichten.
• Einfachere Updates
  Die Aktualisierung erfolgt künftig über reguläre Windows-Update-Mechanismen. Das erleichtert insbesondere in größeren Umgebungen den Rollout und die Wartung.
• Bewährte Funktionen bleiben erhalten
  Die bekannten Features wie benutzerdefinierte Konfigurationsdateien, fein granulierte Event-Filter oder die umfangreiche Protokollierung von Systemaktivitäten werden weiterhin unterstützt.
• Erweiterte Dokumentation und zukünftige Features
  Microsoft plant verbesserte Dokumentationen sowie zusätzliche Verwaltungs- und Sicherheitsfunktionen, darunter neue Optionen für Enterprise-Management und KI-gestützte Bedrohungserkennung.

Bedeutung für Unternehmen und IT-Administratoren

• Erhöhte Standardisierung
  Da Sysmon nun ein offizieller Bestandteil des Betriebssystems wird, kann es einfacher in Standard-Images und Baselines integriert werden.
• Besseres Sicherheitsmonitoring
  Durch die verbesserte Abdeckung und die niedrigere Einstiegshürde profitieren Unternehmen von konsistenterer Protokollierung verdächtiger Aktivitäten.
• Weniger Aufwand bei Deployment und Verwaltung
  Ohne manuelle Installation oder Updateroutinen lässt sich Sysmon einfacher betriebsweit einführen – gerade in größeren IT-Landschaften.
• Nahtlose Integration in bestehende Security-Workflows
  Die bekannten Ereignistypen und Konfigurationsmöglichkeiten bleiben bestehen und können weiterhin in SIEM-, SOC- und Forensik-Prozessen genutzt werden.

Hinweise zur praktischen Umsetzung

• Eine durchdachte Sysmon-Konfiguration bleibt entscheidend: Nur sinnvoll gefilterte Ereignisse sorgen für wertvolle Logs und vermeiden unnötige Datenmengen.
• In Unternehmensumgebungen empfiehlt sich weiterhin ein zentrales Management, z. B. über Gruppenrichtlinien oder Konfigurationsmanagement-Systeme.
• Bestehende Installationen sollten hinsichtlich Migration und Kompatibilität geprüft werden – insbesondere, wenn spezielle Konfigurationsdateien oder externe Versionen im Einsatz sind.

Fazit

Die Integration von Sysmon direkt in Windows 11 und Windows Server 2025 ist ein bedeutender Schritt für die Sicherheitsüberwachung in Unternehmensumgebungen. Sie reduziert den administrativen Aufwand, verbessert die Standardisierung und stärkt die Möglichkeiten für tiefergehende Analysen. Gleichzeitig bleibt eine sorgfältige Konfiguration und Einbettung in bestehende Sicherheitsprozesse weiterhin unerlässlich.

n den letzten Wochen wurde eine neue, besonders raffinierte Phishing-Technik bekannt, die zeigt, wie Angreifer selbst modernste KI-Tools und Cloud-Plattformen für ihre Zwecke missbrauchen können. Sicherheitsforscher von Datadog entdeckten eine Kampagne namens „CoPhish“, die Microsofts Copilot Studio-Agenten nutzt, um OAuth-Tokens zu stehlen – also digitale Schlüssel, mit denen sich Nutzer gegenüber Cloud-Diensten authentifizieren.

Der Fall ist nicht nur ein Beispiel für geschicktes Social Engineering, sondern auch ein Weckruf: Sicherheit durch Vertrauen reicht nicht mehr. Nur eine konsequent umgesetzte Zero-Trust-Architektur kann solchen Angriffen standhalten.

---

Wie funktioniert der CoPhish-Angriff?

Der Angriff nutzt aus, dass in Microsoft Copilot Studio Agenten (Chatbots) erstellt werden können, die über eine öffentliche, legitime Microsoft-Domain erreichbar sind.
Ein Angreifer erstellt dabei einen „bösartigen“ Copilot-Agenten, der scheinbar harmlose Aufgaben erfüllt – etwa das Abrufen von Informationen oder die Anmeldung bei einem Cloud-Service.

Im Hintergrund ist der Agent aber mit einer bösartigen Multi-Tenant-App verknüpft.
Wenn ein ahnungsloser Nutzer auf den Link klickt, öffnet sich ein bekannter Microsoft-Login-Dialog und der Nutzer wird gebeten, einer App Zugriff zu gewähren.
Die URL, das Layout und die Domain wirken absolut vertrauenswürdig – denn sie stammen von Microsoft selbst.

Doch hinter dieser Fassade steckt ein Phishing-Flow, der nach dem Login das OAuth-Token des Benutzers an den Angreifer überträgt. Dieses Token erlaubt dem Angreifer, sich als der Benutzer auszugeben – ohne Passwort, MFA oder sichtbare Anomalien.

Das Perfide: Es handelt sich nicht um einen klassischen Phishing-Link oder eine gefälschte Domain, sondern um Missbrauch einer legitimen Plattformfunktion.

---

Warum klassische Schutzmaßnahmen hier versagen

Traditionelle Sicherheitsansätze verlassen sich auf Vertrauen in bekannte Marken, Zertifikate und Domains.
Doch genau dieses Vertrauen wird hier ausgenutzt.

Selbst Firewalls, Secure Web Gateways oder MFA können nur eingeschränkt helfen, wenn der Nutzer bewusst (aber ahnungslos) einer legitimen App Berechtigungen erteilt.
Der Angriffsvektor liegt nicht in einem Exploit, sondern in einem Missbrauch der Zustimmungskette – etwas, das sich technisch kaum verhindern lässt, solange jeder Benutzer eigenständig Apps autorisieren darf.

---

Zero Trust als Antwort: Vertrauen ist keine Sicherheitsstrategie

Hier zeigt sich der wahre Wert von Zero Trust.
Zero Trust bedeutet nicht „Misstrauen gegenüber allem“, sondern: Jede Anfrage muss kontinuierlich geprüft, kontextualisiert und autorisiert werden – unabhängig von Quelle oder Identität.

Ein echter Zero-Trust-Ansatz hätte mehrere Verteidigungsschichten gegen CoPhish geboten:

1. Strikte Kontrolle über App-Zustimmungen:
   Nur bestimmte Benutzergruppen dürfen OAuth-Zustimmungen erteilen oder neue Anwendungen registrieren.
2. Identitätsbasierte Segmentierung:
   Selbst wenn ein Token kompromittiert wird, sind dessen Berechtigungen auf das Minimum reduziert (Least Privilege).
   Der Zugriff auf sensible Systeme wäre damit ausgeschlossen.
3. Adaptive Authentifizierung und Kontextprüfung:
   Wird ein Token von einem unbekannten Agenten oder ungewöhnlichem Ort verwendet, schlägt eine automatische Re-Authentifizierung oder Policy-Blockade an.
4. Monitoring & Alerting in Echtzeit:
   Zero-Trust-Architekturen setzen auf Telemetrie – ungewöhnliche OAuth-Zustimmungen oder App-Registrierungen werden erkannt und gemeldet.
5. Klar definierte Vertrauenszonen:
   Nur Anwendungen und Agenten, die durch Governance-Prozesse geprüft und zertifiziert sind, dürfen Zugriff auf Unternehmensdaten haben.

---

Schutzmaßnahmen in der Praxis

Wer Microsoft- oder andere Cloud-Dienste betreibt, sollte folgende Punkte prüfen:

• App-Consent Policies aktivieren: Nur Administratoren dürfen neuen Apps Berechtigungen erteilen.
• Überwachung von App-Registrierungen: Regelmäßig prüfen, welche Anwendungen Zugriff auf Entra ID (ehemals Azure AD) haben.
• Rollen und Berechtigungen reduzieren: Least-Privilege konsequent umsetzen.
• Schulungen und Awareness-Programme: Nutzer sollten OAuth-Zustimmungsdialoge kritisch prüfen.
• Zero-Trust-Governance etablieren: Kein System, keine Identität und kein Agent sollte per se als vertrauenswürdig gelten.

---

Fazit

Der CoPhish-Angriff zeigt eindrucksvoll, wie Angreifer legitime Plattformen als trojanische Pferde nutzen.
Die Lösung liegt nicht in noch mehr Firewalls oder Filtern, sondern in einem Paradigmenwechsel: Vertrauen muss ersetzt werden durch überprüfbare Sicherheit.

Zero Trust ist kein Buzzword mehr, sondern eine Notwendigkeit.
In einer Welt, in der sogar Microsoft-Domains zum Einfallstor werden können, gilt:

„Never trust, always verify.“