mars solutions GmbH

Teams-Phishing ohne Fake-Login: Consent-Phishing

Technischer Support — Tue, 11 Aug 2026 09:15:52 +0000

Teams-Phishing ohne Fake-Login: Consent-Phishing

von Technischer Support
August 11, 2026
11:15

Phishing lebte jahrelang von der Fälschung: nachgebaute Login-Seiten, Domains mit einem vertauschten Buchstaben, schlecht kopierte Logos. Genau darauf sind die meisten Schutzmechanismen trainiert.

Nun haben Angreifer unlängst Medienberichten zufolge mehr als 200 Phishing-E-Mails an Mitarbeiter von rund 120 Unternehmen weltweit verschickt.

Genutzt wurde eine Methode, die ohne Fälschung auskommt: Consent-Phishing.
Die Opfer landen auf der echten Microsoft-Anmeldeseite. Erbeutet wird in diesem Fall nicht das Passwort, sondern eine Berechtigung.

Das Wichtigste zu Consent-Phishing im Überblick

Der Köder imitiert eine Teams-/Planner-Benachrichtigung mit HR-Bezug und künstlichem Zeitdruck.
Der Link führt auf eine echte login.microsoftonline.com-OAuth-URL – keine Look-alike-Domain.
Nach der regulären Anmeldung soll einer angreiferkontrollierten App zugestimmt werden.
Bei Zustimmung sind E-Mails, Dateien, SharePoint, OneDrive, Teams-Chats und Kalender offen.

Ablauf Consent-Phishing Angriff

Der Ablauf ist bewusst unauffällig, weil jeder einzelne Schritt für sich betrachtet legitim wirkt: eine erwartbare Benachrichtigung, eine bekannte Absenderadresse, eine echte Anmeldeseite.

Genau diese Kette aus unverdächtigen Einzelschritten macht die Kampagne wirksam – der entscheidende Moment ist erst der Berechtigungsdialog am Ende.

Der Köder

Eine E-Mail imitiert eine Microsoft-Teams- bzw. Planner-Benachrichtigung: „Es gibt neue Aktivität in Ihrem Team.“ Inhaltlich geht es um neue Aufgaben oder Nachrichten aus der Personalabteilung – häufig mit Bezug auf Gehalt, Vergütung und Zusatzleistungen. Ein Hinweis auf „mehrere überfällige Mitarbeiteraufgaben“ erzeugt Zeitdruck.

Die vertraute Absenderadresse

Die sichtbare Absenderadresse gehört zur Organisation des Ziels. Für den Empfänger sieht die Nachricht damit aus wie interne Kommunikation – ein Prüfkriterium, auf das viele Anwender geschult sind, fällt damit aus.

Die echte Microsoft-Anmeldeseite

Der Link öffnet eine legitime OAuth-Autorisierungs-URL auf login.microsoftonline.com. Zertifikat, Domain und Optik stimmen, weil es sich tatsächlich um Microsoft handelt. Die Anmeldung inklusive MFA läuft völlig regulär ab.

Die Zustimmungsabfrage

Anschließend erscheint ein echter Microsoft-Berechtigungsdialog. Er fordert Zugriff für eine Anwendung an, die von den Angreifern kontrolliert wird – teilweise mit der Aufforderung, im Namen der gesamten Organisation zuzustimmen.

Der Zugriff

Nach der Zustimmung leitet Microsoft auf einen von den Angreifern betriebenen Endpunkt weiter – in der beobachteten Kampagne ein AWS-API-Gateway. Die Anwendung besitzt nun ein gültiges Token und verhält sich gegenüber Microsoft 365 wie ein berechtigter Client.

Entscheidend beim Consent-Phishing ist nicht ein einzelnes Passwort, sondern der Umfang der erteilten Berechtigungen.

Bereich	Möglicher Zugriff	Risiko für das Unternehmen
Exchange Online	E-Mails lesen und versenden	Business E-Mail Compromise von einer internen Adresse aus
SharePoint	Dokumente und Bibliotheken lesen	Abfluss von Verträgen, Angeboten, Personalunterlagen
OneDrive	Dateien lesen und verwalten	Unbemerkter Datenabzug aus persönlichen Ablagen
Microsoft Teams	Chats und Kanalinhalte einsehen	Mitlesen interner Abstimmungen, Social Engineering mit Insiderwissen
Kalender	Termine und Teilnehmer einsehen	Zielgenaue Folgeangriffe auf Führungskräfte und Projekte

Besonders kritisch

Der Postfachzugriff erlaubt Folgeangriffe und Business-E-Mail-Compromise-Versuche von einer Adresse aus, der die Empfänger vertrauen.
Aus Sicht der Empfänger gibt es dann kein technisches Warnsignal mehr.

Warum die Erkennung bei Consent-Phishing versagt

Die etablierten Kontrollen prüfen im Kern zwei Dinge:
Ist die Domain gefälscht? Sieht die Login-Seite nachgebaut aus? Beides trifft hier nicht zu.

Klassisches Phishing

Consent-Phishing

Auch MFA hilft hier nur bedingt:
Die Mehr-Faktor-Authentifizierung wird korrekt durchlaufen. Der Zugriff entsteht erst danach – durch die bewusst erteilte Zustimmung.

Microsoft-365-Tenant prüfen

Vor jeder Maßnahme – auch bei Prävention für Consent-Phishing – steht die Bestandsaufnahme. Diese Wege werden IT-Admins empfohlen:

Entra Admin Center → Unternehmensanwendungen: Apps nach Erstellungsdatum sortieren und unbekannte Einträge prüfen.
Überwachungsprotokolle: nach der Aktivität „Consent to application“ filtern.
Berechtigungen bewerten: Wer darf Mail.Read, Mail.Send, Files.Read.All oder offline_access?
Postfachregeln kontrollieren – automatische Weiterleitungen sind ein typisches Folgeartefakt.
Defender for Cloud Apps / App Governance: OAuth-Apps mit hohem Berechtigungsumfang bewerten.

PowerShell · Microsoft Graph

# Verbindung zu Microsoft Graph herstellen
Connect-MgGraph -Scopes "Directory.Read.All","Application.Read.All","AuditLog.Read.All"

# Erteilte delegierte Berechtigungen auflisten
Get-MgOauth2PermissionGrant -All |
  Select-Object ClientId, ConsentType, PrincipalId, Scope |
  Sort-Object ClientId

Wird eine verdächtige Anwendung gefunden, reicht das Deaktivieren nicht aus. Die Zustimmung muss entzogen und die bestehende Sitzung beendet werden.

PowerShell · Bereinigung

# Zustimmung entziehen
Remove-MgOauth2PermissionGrant -OAuth2PermissionGrantId ""

# Aktive Token des betroffenen Kontos entwerten
Revoke-MgUserSignInSession -UserId "benutzer@ihre-domain.de"

Schutzmaßnahmen für Unternehmen

Technisch

Benutzerzustimmung in Entra ID einschränken – idealerweise nur für verifizierte Herausgeber und Berechtigungen mit geringer Auswirkung. Admin-Consent-Workflow aktivieren, damit Anfragen kontrolliert im Team landen. Conditional Access und Anmelderisiko-Richtlinien ergänzen die Kontrolle. MDR sorgt zudem dafür, dass im Falle fehlgeschlagener Richtlinien und Antivirus-Erkennungen rechtzeitig reagiert werden kann.

Organisatorisch

Einen festen Freigabeprozess für neue Anwendungen etablieren. App-Berechtigungen turnusmäßig überprüfen und nicht mehr genutzte Zustimmungen entziehen. Audit-Logs auf Consent-Ereignisse überwachen und als Alarm hinterlegen.

Menschlich

Anwender darauf schulen, Berechtigungsdialoge tatsächlich zu lesen. Dienste im Zweifel direkt über die installierte App öffnen statt über den Link in der Mail. Ungewöhnlich dringliche HR-Themen und mehrere Buttons auf dieselbe URL gehören gemeldet.

Typische Fehler vermeiden

Sich allein auf Domain- und Zertifikatsprüfung verlassen – hier ist beides echt.
„Im Namen Ihrer Organisation zustimmen“ anklicken, ohne die Anwendung zu kennen.
Nach einem Vorfall nur das Passwort zurücksetzen: bestehende Token bleiben gültig.
Eine verdächtige App nur deaktivieren, ohne die Zustimmung zu entziehen.
Benutzerzustimmung uneingeschränkt lassen, weil „das noch nie ein Problem war“.

Nicht zu empfehlen

Verdächtige Anwendungen nicht stillschweigend löschen, bevor die Protokolle gesichert sind – sonst fehlt die Grundlage für die Aufarbeitung.
Zudem Benutzerzustimmung nicht pauschal wieder freigeben, weil einzelne Tools sonst „nicht funktionieren“.

Empfehlungen für IT-Admins

Sinnvoll ist ein gestaffeltes Vorgehen statt einer einmaligen Aktion:

Inventur: alle erteilten App-Berechtigungen im Tenant erfassen und bewerten.
Benutzerzustimmung einschränken und den Admin-Consent-Workflow aktivieren.
Monitoring auf Consent-Ereignisse einrichten und als Alarm hinterlegen.
Awareness-Einheit zum Thema Berechtigungsdialoge in die nächste Schulung aufnehmen.
Incident-Playbook um den Schritt „Zustimmung entziehen und Token widerrufen“ ergänzen.

FAQ zu Consent-Phishing

Schützt MFA vor Consent-Phishing?

Nur bedingt. Die Mehr-Faktor-Authentifizierung wird regulär und erfolgreich durchlaufen. Der Zugriff entsteht erst durch die anschließend erteilte App-Zustimmung.

Reicht ein Passwort-Reset nach einem Vorfall?

Nein. Zustimmung entziehen, Anwendung entfernen, Sitzungen und Token widerrufen, danach Postfach und Weiterleitungsregeln prüfen.

Kann man die Benutzerzustimmung komplett unterbinden?

Ja. In Entra ID lässt sich die Benutzerzustimmung einschränken oder ganz deaktivieren. In Kombination mit dem Admin-Consent-Workflow bleibt der Betrieb arbeitsfähig.

Fazit

Nicht jeder Angriff braucht eine Fälschung. Wenn die legitime Infrastruktur selbst zum Werkzeug wird – wie hier beim Consent-Phishing -verschiebt sich die Verteidigung von der Domain-Prüfung hin zur konsequenten Verwaltung von App-Berechtigungen.

IT-News

OWAReaper: Half-Click-Exploit übernimmt Exchange-Postfächer

31. Juli 2026

Zum Blogbeitrag

IT-News

Windows 11-Update KB5094126: Bugs in Office, File Explorer und Papierkorb

24. Juni 2026

Zum Blogbeitrag

IT-News

NIS-2-Registrierung: Frist abgelaufen, Lücke bleibt

5. August 2026

Zum Blogbeitrag

Fanden Sie den Blogbeitrag hilfreich und interessant?

Vielen Dank für Ihre Rückmeldung!

Der Beitrag Teams-Phishing ohne Fake-Login: Consent-Phishing erschien zuerst auf mars solutions GmbH.

NIS-2-Registrierung: Frist abgelaufen, Lücke bleibt

Technischer Support — Wed, 05 Aug 2026 08:28:49 +0000

NIS-2-Registrierung: Frist abgelaufen, Lücke bleibt

Technischer Support
August 5, 2026
10:28

Am 31. Juli 2026 ist die Nachfrist für die NIS-2-Registrierung beim Bundesamt für Sicherheit in der Informationstechnik (BSI) abgelaufen. Von den rund 29.500 betroffenen Unternehmen und Bundesbehörden waren zuletzt etwa 18.500 im BSI-Portal erfasst.

Es fehlen damit rund 11.000 Einrichtungen – gut ein Drittel. Die Registrierung ist dabei keine Formalie: Sie ist eine gesetzliche Pflicht nach § 33 BSIG, und ihr Versäumnis ist ein eigenständiger Bußgeldtatbestand.

Dieser Beitrag informiert, wer betroffen ist, wie die NIS-2-Registrierung abläuft, welche Bußgelder drohen und welche Pflichten mit dem Eintrag im BSI-Portal erst beginnen.

Das Wichtigste zur NIS-2 Registrierung im Überblick

Das NIS2-Umsetzungsgesetz gilt in Deutschland seit dem 6. Dezember 2025, die gesetzliche Registrierungsfrist nach § 33 BSIG endete am 6. März 2026.
Der vom BSI genannte 31. Juli 2026 war keine Fristverlängerung, sondern eine Vollzugszurückhaltung der Aufsicht.
Betroffene Einrichtungen müssen sich selbst identifizieren - es gibt keine Bescheide und keine Aufforderung durch eine Behörde.
Eine fehlende Registrierung kann mit bis zu 500.000 Euro geahndet werden, Mängel im Risikomanagement nach § 30 BSIG mit bis zu 10 Millionen Euro.
Nach der Registrierung greifen Meldepflichten mit 24-Stunden-Frist und die persönlichen Pflichten der Geschäftsleitung nach § 38 BSIG.

Warum die NIS-2-Registrierung stockt

Das NIS-2-Umsetzungs- und Cybersicherheitsstärkungsgesetz trat am 6. Dezember 2025 in Kraft, das Meldeportal des BSI ging am 6. Januar 2026 in Betrieb. Die gesetzliche Drei-Monats-Frist des § 33 BSIG endete damit am 6. März 2026 – zu diesem Zeitpunkt hatte sich nur ein Bruchteil der erwarteten Einrichtungen gemeldet.

Juristisch ist eine Unterscheidung wichtig: Eine Behörde kann eine gesetzliche Frist nicht verlängern. Das BSI hat lediglich angekündigt, Nachmeldungen bis zum 31. Juli 2026 zu akzeptieren und bis dahin von Sanktionen abzusehen. Der Ordnungswidrigkeitentatbestand bestand seit dem 7. März 2026 – und besteht weiter. Wer die NIS-2-Registrierung jetzt nachholt, beendet den laufenden Verstoß, nicht die Vergangenheit.

Zahlen zur Registrierungslücke

Das BSI erwartet rund 29.500 registrierungspflichtige Einrichtungen. Registriert waren zuletzt etwa 18.500 – die Lücke umfasst damit rund 11.000 Unternehmen und Bundesbehörden.

Viele Unternehmen wissen nicht, dass sie betroffen sind, weil die Zuordnung über Sektor, Teilsektor und Größenklasse erfolgt und nicht über eine behördliche Mitteilung. Cybersicherheit werde „vielerorts noch immer nicht genug Priorität eingeräumt“, Anforderungen würden als „administratives Ärgernis“ statt als Risikomanagement behandelt, so die Aussage von Experten. Die Registrierungslücke sei deshalb ein Indikator für eine dahinterliegende Resilienzlücke.

Wer zur NIS-2-Registrierung verpflichtet ist

Die Betroffenheit ergibt sich aus zwei Kriterien, die gemeinsam erfüllt sein müssen: Sektorzugehörigkeit und Unternehmensgröße. Die Anlagen 1 und 2 des BSIG listen 18 Sektoren, darunter Energie, Verkehr, Gesundheit, Wasser, digitale Infrastruktur, IT-Dienstleistungen, Chemie, Lebensmittel und verarbeitendes Gewerbe.

Die Größenschwellen orientieren sich an der EU-KMU-Definition: Betroffen sind Unternehmen mit mindestens 50 Beschäftigten oder mit mehr als 10 Millionen Euro Jahresumsatz und Bilanzsumme. Als besonders wichtige Einrichtung gilt, wer in einem Sektor der Anlage 1 mindestens 250 Beschäftigte hat oder über 50 Millionen Euro Umsatz und mehr als 43 Millionen Euro Bilanzsumme erreicht, Betreiber kritischer Anlagen unabhängig von ihrer Größe. Alle übrigen erfassten Organisationen sind wichtige Einrichtungen – der Unterschied wirkt sich auf Aufsichtsintensität und Bußgeldrahmen aus, nicht auf die NIS-2-Registrierungspflicht selbst.

Kurzinfos dazu: BSI „NIS-2-Meldepflicht“

NIS-2-Registrierung im BSI-Portal

Der technische Ablauf ist zweistufig, und der erste Schritt ist der zeitkritische. Für die Anmeldung am BSI-Meldeportal wird ein Zugang über „Mein Unternehmenskonto“ benötigt, der auf einem ELSTER-Organisationszertifikat basiert. Dessen Beantragung dauert mehrere Werktage, weil ein Teil der Zugangsdaten per Post versendet wird. Die eigentliche Registrierung ist anschließend in unter einer Stunde erledigt.

Infos zu Bußgelder und Haftung

Verstoß	Bußgeldrahmen nach § 65 BSIG
Registrierung fehlt oder ist verspätet (§ 33 BSIG)	bis zu 500.000 Euro
Risikomanagement mangelhaft (§ 30 BSIG), besonders wichtige Einrichtung	bis zu 10 Millionen Euro, ab 500 Millionen Euro Umsatz bis zu 2 Prozent des weltweiten Jahresumsatzes
Risikomanagement mangelhaft (§ 30 BSIG), wichtige Einrichtung	bis zu 7 Millionen Euro beziehungsweise 1,4 Prozent des weltweiten Jahresumsatzes

§ 38 BSIG verpflichtet die Geschäftsleitung, die Risikomanagementmaßnahmen zu billigen, ihre Umsetzung zu überwachen und sich selbst regelmäßig zu Cyberrisiken schulen zu lassen. Diese Pflichten sind nicht delegierbar: Die Bestellung eines Informationssicherheitsbeauftragten verlagert Aufgaben, nicht die Verantwortung. Weil § 30 BSIG zudem eine Dokumentationspflicht enthält, entscheidet im Aufsichtsfall die Nachweislage.

Pflichten nach der NIS-2-Registrierung

Die NIS-2-Registrierung ist ein Eintrag in einer Datenbank, keine Compliance. Materiell verlangt § 30 BSIG zehn Maßnahmenbereiche, Operativ am relevantesten ist die Meldepflicht des § 34 BSIG. Dies sind die wichtigsten Maßnahmen in der Übersicht:

Risikoanalyse und Sicherheitskonzepte - dokumentiert und regelmäßig aktualisiert.
Bewältigung von Sicherheitsvorfällen - definierte Prozesse, Verantwortliche und Meldewege.
Business Continuity und Krisenmanagement - Backup-Konzept, Wiederherstellung, Notbetrieb.
Sicherheit der Lieferkette - Anforderungen an Dienstleister und Zulieferer.
Kryptografie und Zugriffskontrolle - inklusive Multi-Faktor-Authentifizierung für alle Zugriffswege.
Personalsicherheit und Schulungen - für Beschäftigte und Geschäftsleitung.

Empfehlungen für IT-Admins

Die folgenden Punkte bilden die Arbeitsliste, wenn die Registrierung noch offen ist oder der Stand nicht belastbar dokumentiert wurde:

Betroffenheit strukturiert prüfen.
ELSTER-Organisationszertifikat für „Mein Unternehmenskonto" beantragen, falls noch nicht vorhanden.
Registrierungsdaten zusammenstellen.
NIS-2-Registrierung im BSI-Meldeportal abschließen und die Eingangsbestätigung revisionssicher ablegen.
Prozess für Datenänderungen festlegen: Wer meldet neue IP-Bereiche, Kontaktwechsel oder Umfirmierungen an das BSI?
Meldewege in den Notfallplan aufnehmen, Verantwortliche für die 24-Stunden-Erstmeldung benennen und den Ablauf testen.
Lückenanalyse gegen die zehn Maßnahmenbereiche des § 30 BSIG fahren und offene Punkte mit Termin und Verantwortlichkeit versehen.
In Unternehmensgruppen je Rechtseinheit prüfen - die Pflicht trifft die Einrichtung.

Bedeutung für Geschäftsführung und Entscheider

Für die Geschäftsleitung sind drei Punkte relevant:

1. ist die NIS-2-Registrierung der sichtbarste Teil der Pflichten und damit der einfachste Prüfpunkt für die Aufsicht: Ob eine Einrichtung registriert ist, lässt sich ohne Vor-Ort-Prüfung feststellen.

2. verschiebt sich der Aufwand nach hinten, aber man muss reagieren. Die Kette aus Betroffenheitsprüfung, Zugangsbeantragung, Registrierung und Lückenanalyse lässt sich planvoll über Monate abarbeiten – oder unter Aufsichtsdruck in wenigen Wochen.

3. wirkt NIS-2 zunehmend über den Markt: Ausschreibungen, Versicherer und Kunden aus regulierten Sektoren fragen den Umsetzungsstand aktiv ab. Auch nicht betroffene Unternehmen begründen ihren Status daher besser mit einer dokumentierten Prüfung.

FAQ zur NIS-2-Registrierung

Muss ich mich nach dem 31. Juli 2026 noch registrieren?

Ja. Die gesetzliche Frist des § 33 BSIG endete bereits am 6. März 2026, der 31. Juli 2026 war lediglich eine Vollzugszurückhaltung des BSI. Die Registrierungspflicht besteht unverändert und sollte unverzüglich nachgeholt werden.

Woran erkenne ich, ob mein Unternehmen betroffen ist?

An Sektor und Größe. Betroffen sind Einrichtungen aus den Sektoren der Anlagen 1 und 2 BSIG mit mindestens 50 Beschäftigten oder mehr als 10 Millionen Euro Umsatz und Bilanzsumme. Eine behördliche Mitteilung gibt es nicht - die Prüfung obliegt dem Unternehmen und sollte dokumentiert werden.

Was kostet eine fehlende NIS-2-Registrierung?

Bis zu 500.000 Euro nach § 65 BSIG. Mängel im Risikomanagement nach § 30 BSIG sind deutlich höher bedroht: bis zu 10 Millionen Euro oder 2 Prozent des weltweiten Jahresumsatzes bei besonders wichtigen Einrichtungen.

Wie lange dauert die NIS-2-Registrierung beim BSI?

Der Eintrag im BSI-Meldeportal ist bei vollständiger Vorbereitung in unter einer Stunde erledigt. Zeitkritisch ist das ELSTER-Organisationszertifikat für „Mein Unternehmenskonto", dessen Beantragung mehrere Werktage in Anspruch nimmt.

Welche Pflichten gelten nach der NIS-2-Registrierung?

Risikomanagement nach § 30 BSIG mit zehn Maßnahmenbereichen und Dokumentationspflicht, Meldepflichten nach § 34 BSIG mit 24 Stunden, 72 Stunden und einem Monat sowie die persönlichen Pflichten der Geschäftsleitung nach § 38 BSIG.

Fazit

Die NIS-2-Registrierungslücke von rund 11.000 Einrichtungen zeigt vor allem ein Informations- und Priorisierungsproblem, kein technisches.
Die NIS-2-Registrierung selbst ist in unter einer Stunde erledigt, sobald der Zugang über „Mein Unternehmenskonto“ steht. Aufwendig sind die Vorarbeit – die belastbare Betroffenheitsprüfung – und die Umsetzung danach.

Mit dem 31. Juli 2026 ist die Phase der Nachsicht beendet, die Pflicht aber unverändert in Kraft. Wer die eigene Einordnung bisher nicht dokumentiert hat, sollte damit beginnen: Sie ist die Grundlage für alles Weitere und im Zweifel der erste Nachweis, den die Aufsicht sehen will.

Weitere interessante Beiträge

IT-News

Password Spraying: Wenn Microsoft 365 zur Zielscheibe wird

1. Juli 2026

Zum Blogbeitrag

IT-News

Microsoft Exchange Zero-Day CVE-2026-42897: Warum Unternehmen jetzt handeln müssen

20. Mai 2026

Zum Blogbeitrag

IT-News

Windows 11-Update KB5094126: Bugs in Office, File Explorer und Papierkorb

24. Juni 2026

Zum Blogbeitrag

Fanden Sie den Blogbeitrag hilfreich und interessant?

Vielen Dank für Ihre Rückmeldung!

Der Beitrag NIS-2-Registrierung: Frist abgelaufen, Lücke bleibt erschien zuerst auf mars solutions GmbH.

OWAReaper: Half-Click-Exploit übernimmt Exchange-Postfächer

Technischer Support — Fri, 31 Jul 2026 08:46:49 +0000

OWAReaper: Half-Click-Exploit übernimmt Exchange-Postfächer

Technischer Support
Juli 31, 2026
10:46

Seit dem 22. Juli 2026 werden lokale Exchange-Server über Outlook Web Access angegriffen und dort das Schadprogramm OWAReaper installiert. Ausgenutzt wird CVE-2026-42897, eine Cross-Site-Scripting-Schwachstelle mit einem CVSS-Wert von 8,1, die Microsoft am 14. Mai 2026 als aktiv angegriffen gemeldet und erst am 9. Juni 2026 mit einem Update geschlossen hat.

Das Öffnen der Mail im Lesebereich genügt – ein Klick auf Link oder Anhang ist nicht nötig. Betroffen sind ausschließlich Exchange-Server im eigenen Rechenzentrum, Exchange Online nicht.

Das Wichtigste in Kürze

OWAReaper ist ein JavaScript-Implantat, das vollständig im Browser innerhalb der OWA-Sitzung läuft - laut Proofpoint das bislang ausgereifteste Half-Click-Implantat, das das Unternehmen beobachtet hat.
Ausgenutzt wird CVE-2026-42897 (CVSS 8,1 nach Microsoft-Bewertung), eine XSS-Lücke in Outlook Web Access von Exchange Server Subscription Edition, 2016 und 2019 - Exchange Online ist nicht betroffen.
Das Öffnen der präparierten Mail im Lesebereich reicht zur Infektion; anschließend entfernt der Schadcode seine eigenen Spuren aus der Nachricht auf dem Server.
OWAReaper übersteht Passwortwechsel und selbst die Neuinstallation des Endgeräts, weil der Zugang im Postfach und in Exchange-Ordnerrechten verankert wird.
Sofort prüfen: Juni-Sicherheitsupdates einspielen (Exchange SE: KB5094139), Ordnerrechte für den Benutzer „Default“ kontrollieren, EWS-Token der Outlook-Add-ins widerrufen.

So läuft der OWAReaper-Angriff ab

Am 22. Juli 2026 begann eine breite Angriffswelle, die das Sicherheitsunternehmen Proofpoint am 29. Juli 2026 öffentlich beschrieben hat. Die Mails kommen aus zuvor gehackten Konten und tragen unauffällige Köder – Analysen zu Halbleiter-Lieferketten oder Kennzahlenberichte zur Tourismusbranche. Die Streuung ist bewusst breit gehalten, damit die Kampagne im normalen Massenmail-Rauschen untergeht.

Im Fokus stehen Regierungsstellen in den USA und Europa sowie Unternehmen aus Telekommunikation, Finanzwesen, Hotellerie und Luft- und Raumfahrt.

Die Angriffsinfrastruktur wurde laut Proofpoint bereits im März 2026 aufgebaut, zwei Monate vor der Microsoft-Meldung. Die Lücke wurde also vermutlich schon vorher in kleinerem Umfang als Zero-Day genutzt.

Zahlen, Daten, Fakten

Die wichtigsten Kennzahlen zur Schwachstelle und zur laufenden Kampagne im Überblick:

8,1 CVSS-Wert nach Microsoft-Bewertung - das NVD führt die Lücke mit 6,1
14.05.2026 Microsoft-Advisory mit bestätigter Ausnutzung, das Update kam erst am 09.06.2026
3 voneinander unabhängige Persistenzwege in einem einzigen Implantat
2 Command-and-Control-Kanäle und zwei getrennte Exfiltrationsverfahren

Warum der Half-Click-Exploit funktioniert

Die Ursache liegt im Server: Exchange bereinigt das HTML im Nachrichtenkörper nicht ausreichend. In der präparierten Mail steckt ein onload-Ereignishandler, der beim Aufbau der Nachricht im Lesebereich automatisch ausgelöst wird. Er setzt den eigentlichen Schadcode aus Base64-Fragmenten zusammen, die in den Social-Media-Symbolen der Nachricht versteckt sind. Weitere Daten liegen hinter einem Raute-Zeichen, damit der Browser sie beim Seitenaufruf nicht mitüberträgt.

Half-Click erklärt

Beim klassischen Phishing braucht es einen vollen Klick – auf einen Link oder einen Anhang. Beim Half-Click-Exploit genügt die halbe Handlung: das Öffnen beziehungsweise die Vorschau der Nachricht. Awareness-Schulungen greifen hier nicht mehr, weil es keine erkennbare Entscheidung des Nutzers gibt.

Der Code läuft im Browser-Kontext der angemeldeten OWA-Sitzung, also mit allen Rechten des Postfachbesitzers. Als erste Aktion schreibt OWAReaper die auslösende Nachricht auf dem Server um und entfernt den Exploit-Code daraus – bei einer späteren Prüfung sieht die Mail harmlos aus.

Wie OWAReaper im Postfach bleibt

Das Implantat sammelt gespeicherte OWA-Zugangsdaten über unsichtbare Eingabefelder, die das Ausfüllen durch den Browser auslösen. Zusätzlich sucht es Outlook-Add-ins mit der Berechtigung ReadWriteMailbox und stiehlt deren OAuth-Token für die Exchange Web Services. Über einen regulären Ordner-Befehl vergibt es dem Standardbenutzer „Default“ Besitzerrechte auf alle Mailordner – ein Zugang, der von außen wie eine normale Berechtigung aussieht.

1

Verschlüsselt im Browser-Speicher

Im localStorage-Schlüssel PageDataPayload.OwaUserDefaultSettings, der bei jeder OWA-Synchronisierung wieder ausgeführt wird.

2

In den Server-Ordnerrechten

Der Zugriff über gestohlene EWS-Token und die vergebenen Besitzerrechte übersteht Passwortwechsel und Geräte-Neuinstallation.

3

Im Offline-Cache

Versteckte iframes in zwischengespeicherten Nachrichten der IndexedDB-Datenbank owa_offline_db starten den Code erneut, sobald die Mail wieder geöffnet wird.

Befehle holt sich das Implantat über zwei Kanäle: alle 24 Stunden über die Commit-Suche der GitHub-API und zusätzlich aus eingehenden Mails der Betreiber, deren Offline-Cache alle fünf Minuten geprüft wird. Gestohlene Daten fließen per HTTPS mit verschlüsselten URI-Pfaden über legitime CDN-Dienste ab; scheitert das, weicht OWAReaper auf getunnelte DNS-Anfragen aus. Beides fällt in normalen Netzwerkprotokollen kaum auf.

Patchstand gegen CVE-2026-42897 prüfen

Microsoft veröffentlichte das Advisory am 14. Mai 2026 zunächst ohne Update und mit einer Übergangsmaßnahme: Wer den Exchange Emergency Mitigation Service aktiv hat – Standard in aktuellen Installationen -, erhielt die Gegenmaßnahme automatisch; alternativ ließ sie sich per Exchange On-premises Mitigation Tool nachziehen.

Produkt	Stand zu CVE-2026-42897	Was zu tun ist
ProduktExchange Server Subscription Edition	Stand zu CVE-2026-42897Update verfügbar: SU7 (KB5094139) vom 09.06.2026	Was zu tun istUpdate einspielen und Build gegenprüfen
ProduktExchange Server 2019	Stand zu CVE-2026-42897Update nur über ESU – Support endete am 14.10.2025	Was zu tun istESU-Berechtigung klären, Update einspielen, Migration terminieren
ProduktExchange Server 2016	Stand zu CVE-2026-42897Update nur über ESU – Support endete am 14.10.2025	Was zu tun istESU-Berechtigung klären, Update einspielen, Migration terminieren
ProduktExchange Online / Microsoft 365	Stand zu CVE-2026-42897Nicht betroffen	Was zu tun istIn Hybrid-Umgebungen die lokalen Server prüfen

Das eigentliche Update kam mit den Juni-Sicherheitsupdates am 9. Juni 2026. Exchange Server 2016 und 2019 sind seit dem 14. Oktober 2025 außerhalb des Supports – Updates gibt es dort nur noch über das kostenpflichtige ESU-Programm, dessen zweite Periode bis Ende Oktober 2026 läuft und einen Enterprise Agreement voraussetzt. Wer diese Versionen ohne ESU betreibt, hat für CVE-2026-42897 keinen Patch und ist allein auf die Mitigation angewiesen. Die Hintergründe zur Lücke selbst haben wir im Beitrag zum Exchange-Zero-Day CVE-2026-42897 beschrieben.

Hinweise zum Vorgehen für IT-Admins

Die automatische Mitigation ersetzt das Update nicht.
Sie greift nur, solange der Emergency Mitigation Service aktiv ist und der Server die Microsoft-Dienste erreichen kann.

1

Patchstand feststellen

Alle lokalen Exchange-Server inventarisieren und prüfen, ob die Juni-Sicherheitsupdates installiert sind. Für Exchange 2016 und 2019 klären, ob eine ESU-Berechtigung besteht.

2

Mitigation kontrollieren

Emergency Mitigation Service aktiv, Mitigation angewendet, ausgehende Verbindung zu den Microsoft-Diensten möglich.

3

Ordnerrechte prüfen

Postfächer auf Besitzerrechte für den Benutzer „Default“ durchsuchen. Das ist der auffälligste und am einfachsten prüfbare Hinweis auf eine Kompromittierung.

4

Add-ins und Token auditieren

Outlook-Add-ins mit der Berechtigung ReadWriteMailbox erfassen, nicht benötigte entfernen, EWS-Token widerrufen.

5

Netzwerkseitig blockieren

Ausgehende Verbindungen zu den von Proofpoint veröffentlichten Command-and-Control-Domains sperren und auf auffällige DNS-Anfragen achten.

6

Erkennung nachziehen

Proofpoint hat fünf Signaturen für Exploit, Beacon und Exfiltration veröffentlicht – diese im IDS/IPS beziehungsweise beim Sicherheitsdienstleister aktivieren lassen.

7

Migration bewerten

Für Exchange 2016 und 2019 den Wechsel auf die Subscription Edition oder nach Exchange Online einplanen, statt ESU-Perioden zu verlängern.

So bereinigen Sie betroffene Postfächer

Vergebene Ordnerberechtigungen für „Default“ entfernen und dokumentieren.
OAuth-Token der betroffenen Add-ins widerrufen, danach neu ausrollen.
Im Browser des Nutzers die IndexedDB-Datenbank owa_offline_db und den localStorage-Schlüssel PageDataPayload.OwaUserDefaultSettings löschen.
Erst danach Kennwörter zurücksetzen und Sitzungen widerrufen - vorher bringt der Wechsel nichts, weil die Persistenz nicht am Kennwort hängt.
Postfachinhalte und Weiterleitungsregeln auf Abfluss prüfen und den Vorfall dokumentieren.

OWAReaper - wichtig zu wissen für Unternehmen

Der wirtschaftlich relevante Punkt an diesem Fall ist die Reihenfolge der üblichen Reflexe. Wird ein Konto kompromittiert, folgen normalerweise Kennwortwechsel und Rechnerneuinstallation. Beides läuft hier ins Leere – der Zugang steckt im Postfach und in den Rechten auf dem Server. Ein Vorfall gilt also erst als bereinigt, wenn Berechtigungen und Token nachweislich zurückgesetzt sind, anders als bei reinen Anmeldedaten-Angriffen wie dem Password Spraying gegen Microsoft 365.

Das Risiko ist konkret: Wer Besitzerrechte auf alle Mailordner hat, liest Vertragsentwürfe, Personalunterlagen und Zahlungsverkehr mit – dauerhaft und unauffällig. Sobald personenbezogene Daten betroffen sind, greift die Meldepflicht nach DSGVO innerhalb von 72 Stunden.

Der Aufwand für die Absicherung ist überschaubar: Updates einspielen und Berechtigungen prüfen sind Arbeiten von Stunden. Teurer wird die Frage nach dem Betriebsmodell, denn Exchange 2016 und 2019 erhalten Sicherheitsupdates nur noch über ein kostenpflichtiges Programm mit Enddatum. Wer dort produktiv arbeitet, sollte die Migration jetzt terminieren, statt bei der nächsten Lücke erneut auf eine Übergangsmaßnahme zu hoffen.

FAQ zu OWAReaper

Sind wir mit Exchange Online oder Microsoft 365 betroffen?

Nein. CVE-2026-42897 betrifft nach Angaben von Microsoft ausschließlich lokale Exchange-Server mit Outlook Web Access, konkret die Subscription Edition sowie Exchange 2016 und 2019. Hybrid-Umgebungen sind über ihre lokalen Server dennoch im Risiko.

Hilft ein Kennwortwechsel gegen OWAReaper?

Allein nicht. Die Persistenz beruht auf gestohlenen OAuth-Token und auf Ordnerberechtigungen im Postfach, die einen Kennwortwechsel überdauern. Erst wenn Token widerrufen und Berechtigungen zurückgesetzt sind, wirkt der Wechsel.

Woran erkennen wir, dass wir gehackt wurden?

Der deutlichste Hinweis sind Besitzerrechte für den Benutzer „Default“ auf Mailordnern. Hinzu kommen unerwartete Outlook-Add-ins mit weitreichenden Postfachrechten sowie ausgehende Verbindungen zu den von Proofpoint veröffentlichten Command-and-Control-Domains.

Schützt Multi-Faktor-Authentifizierung vor diesem Angriff?

Nein. Der Schadcode läuft in einer bereits angemeldeten OWA-Sitzung des Nutzers. MFA bleibt trotzdem sinnvoll, verhindert aber weder den Exploit noch die anschließende Übernahme des Postfachs.

Genügt die automatische Mitigation von Microsoft?

Sie ist eine Übergangslösung, kein Ersatz für das Update vom 9. Juni 2026. Bei Exchange 2016 und 2019 ohne ESU-Berechtigung bleibt sie derzeit die einzige Schutzmaßnahme - ein Zustand, der nicht dauerhaft tragfähig ist.

Fazit

OWAReaper zeigt, wie sich Angriffe auf Mailserver verschoben haben: Nicht der Rechner ist das Ziel, sondern das Postfach. Ein Implantat, das im Browser lebt, sich selbst aus der Auslöser-Mail entfernt und über Server-Berechtigungen zurückkehrt, macht die gewohnten Aufräumschritte wirkungslos.

Wer lokale Exchange-Server betreibt, sollte deshalb zwei Dinge parallel erledigen: die Juni-Updates verifizieren und die Ordnerberechtigungen aller Postfächer auf den Benutzer „Default“ prüfen. Und wer Exchange 2016 oder 2019 noch im Betrieb hat, entscheidet mit dem Migrationstermin darüber, wie die nächste Lücke dieser Art ausgeht.

Weitere interessante Beiträge

IT-News

Windows 11-Update KB5094126: Bugs in Office, File Explorer und Papierkorb

24. Juni 2026

Zum Blogbeitrag

IT-News

Windows Defender Sicherheitslücke: Microsoft patcht RoguePlanet-Zero-Day nach

15. Juli 2026

Zum Blogbeitrag

mars-News

Rückblick auf das 2. Managed NMS Symposium 2026

19. Juni 2026

Zum Blogbeitrag

Fanden Sie den Blogbeitrag hilfreich und interessant?

Vielen Dank für Ihre Rückmeldung!

Der Beitrag OWAReaper: Half-Click-Exploit übernimmt Exchange-Postfächer erschien zuerst auf mars solutions GmbH.

Veeam Sicherheitslücke: Veeam-Updater ermöglicht Rechteausweitung

Technischer Support — Fri, 17 Jul 2026 06:12:00 +0000

Veeam Sicherheitslücke: Veeam-Updater ermöglicht Rechteausweitung

Technischer Support
Juli 17, 2026
08:12

Eine Schwachstelle in der Updater-Komponente von Veeam (CVE-2026-56844, CVSS 8.4 von 10, Risiko „hoch“) erlaubt lokalen Benutzern, ihre Rechte bis auf root auszuweiten und damit die volle Kontrolle über das Betriebssystem zu erlangen. Von der Veeam Sicherheitslücke betroffen sind die Appliance-Varianten der Backupsoftware Veeam Backup & Replication, nicht die klassische Windows-Installation. Veeam hat die Lücke mit einer neuen Updater-Version geschlossen.

Überblick

Die Veeam-Updater-Schwachstelle wird als CVE-2026-56844 geführt und mit CVSS 4.0 auf 8.4 von 10 bewertet (Risiko „hoch“).
Ein lokaler Benutzer kann über die Updater-Komponente seine Rechte bis auf root ausweiten und so das Betriebssystem übernehmen.
Betroffen sind die Updater-Komponenten der Veeam Software Appliance (Linux-basierter Backup-Server) und der Veeam Infrastructure Appliance.
Rein Windows-basierte Veeam-Backup-&-Replication-Server sind nicht direkt betroffen, verbundene Remote-Komponenten können es aber sein.
Behoben ist die Lücke in der Updater-Version 12.3.0.65; bei aktiver automatischer Update-Verteilung ist meist kein manueller Eingriff nötig.

Hintergründe zur IT-Sicherheitslücke

Veeam hat am 14. Juli 2026 im Advisory KB4879 eine Schwachstelle in der Updater-Komponente seiner Appliances bekannt gegeben. Über die Lücke kann ein Angreifer, der bereits lokalen Zugriff auf das System hat, seine Berechtigungen bis auf die höchste Ebene (root) anheben. Damit stünde ihm der volle Zugriff auf das Betriebssystem und auf die dort laufenden Backup-Dienste offen.

Veeam ordnet das Risiko trotz der notwendigen lokalen Vorbedingung als „hoch“ ein, weil die Backup-Infrastruktur ein besonders schützenswertes Ziel ist. Es handelt sich aber nicht um eine aus dem Internet ausnutzbare Lücke: Ein Angreifer benötigt zunächst einen Fuß in der Tür, etwa ein bereits gehacktes Benutzerkonto auf der Appliance.

Zahlen, Daten und Fakten

CVSS 8.4 von 10

Bewertung nach CVSS 4.0, Risiko „hoch“. Ausnutzung setzt lokalen Zugriff voraus.

Updater 12.3.0.65

Die fehlerbereinigte Version der Updater-Komponente, die die Lücke schließt.

Advisory KB4879

Von Veeam am 14. Juli 2026 veröffentlicht

Technische Analyse der Schwachstelle

Hinter CVE-2026-56844 steht laut den vorliegenden Schwachstellendaten ein Path-Traversal-Fehler (CWE-22) in der Updater-Komponente. Path Traversal bedeutet, dass eine Anwendung Dateipfade nicht sauber prüft und sich dadurch über Verzeichnisgrenzen hinaus manipulieren lässt.

Der Updater läuft auf den Appliances mit hohen Systemrechten, damit er Komponenten aktualisieren und ersetzen kann. Genau diese privilegierte Stellung macht ihn zum Hebel: Wer den Ablauf manipuliert, kann eigene Befehle im Kontext des root-Benutzers ausführen. Aus einem Konto mit begrenzten Rechten wird so ein vollwertiger Administratorzugang auf Betriebssystemebene.

Wichtige Hinweise

Eine Rechteausweitung ist selten der erste Schritt eines Angriffs, sondern der zweite: Sie verwandelt einen kleinen Einbruch in eine große Infiltrierung. Auf einem Backup-Server wiegt das besonders schwer – denn wer dort root-Rechte erlangt, kann Sicherungen einsehen, verändern oder löschen.

Betroffene und nicht betroffene Systeme

Komponente	Betroffen?
Veeam Software Appliance (Linux-Backup-Server)	Ja – Updater-Komponente betroffen
Veeam Infrastructure Appliance	Ja – Updater-Komponente betroffen
Windows-basierte Installation (Veeam Backup & Replication)	Nein – nicht direkt betroffen
Remote-Komponenten auf Basis der Infrastructure Appliance	Möglich – können verwundbar sein

Prüfen Sie im Zuge der Veeam Sicherheitslücke CVE-2026-56844 nicht nur den zentralen Backup-Server, sondern auch verteilte oder ausgelagerte Komponenten. Gerade in gewachsenen Umgebungen ist nicht immer sofort klar, wo eine Infrastructure Appliance mitläuft. Eine kurze Bestandsaufnahme schafft hier Gewissheit.

Hinweise zum Vorgehen für IT-Admins

1

Update-Verteilung prüfen

Ist die automatische Verteilung aktiviert, wird die fehlerbereinigte Updater-Version in der Regel ohne manuelles Zutun ausgerollt. Kontrollieren Sie, dass dieser Mechanismus aktiv ist und funktioniert.

2

Updater-Version verifizieren

Stellen Sie sicher, dass auf den betroffenen Appliances die Updater-Version 12.3.0.65 oder neuer installiert ist. Eine kurze Kontrolle der Versionsnummer schafft Klarheit.

3

Bestand aufnehmen

Erfassen Sie, welche Appliances (Software Appliance, Infrastructure Appliance) und welche verbundenen Remote-Komponenten laufen, und gleichen Sie sie gegen den betroffenen Umfang ab.

4

Lokalen Zugriff einschränken

Da die Lücke lokalen Zugriff voraussetzt, senkt jede Härtung des Zugangs das Risiko: nicht benötigte Konten entfernen, Anmeldungen protokollieren, Zugriff auf die Appliance beschränken.

5

Backup-Umgebung isolieren

Trennen Sie die Backup-Infrastruktur so weit wie möglich vom übrigen Netz und von produktiven Systemen. So wird der für die Ausnutzung nötige erste Zugriff von vornherein erschwert.

Das unmittelbare Risiko ist beherrschbar, die Tragweite im Ernstfall aber hoch.
Beherrschbar ist die Veeam Sicherheitslücke, weil die Schwachstelle nicht direkt aus dem Internet ausnutzbar ist und der Hersteller bereits eine Korrektur bereitstellt. Dennoch ist die Geafahr als hoch einzustufen, weil es um den Backup-Server geht – das letzte Sicherungsnetz bei Ransomware und Datenverlust.

Der Aufwand zur Absicherung bleibt aber überschaubar: Update-Stand und Zugriffsmöglichkeiten kontrollieren und Backup-Umgebung isolieren.

FAQ

Was genau ist CVE-2026-56844?

Eine Schwachstelle in der Updater-Komponente der Veeam-Appliances. Sie erlaubt einem lokalen Benutzer, seine Rechte bis auf root auszuweiten und damit das Betriebssystem zu übernehmen. Die Bewertung liegt bei CVSS 8.4 von 10 (Risiko „hoch“).

Ist man von der Veeam Sicherheitslücke betroffen, wenn wir Veeam nur unter Windows betreiben?

Eine rein Windows-basierte Installation ist nicht direkt betroffen. Verwenden Sie allerdings Remote-Komponenten, die auf der Veeam Infrastructure Appliance aufsetzen, können diese verwundbar sein. Prüfen Sie daher Ihre gesamte Komponentenlandschaft.

Muss manuell gepatcht werden?

In den meisten Fällen nicht. Ist die automatische Update-Verteilung aktiv, wird die Updater-Version 12.3.0.65 in der Regel automatisch ausgerollt. Kontrollieren Sie zur Sicherheit die installierte Versionsnummer.

Kann die Lücke aus dem Internet ausgenutzt werden?

Nein. Die Rechteausweitung setzt lokalen Zugriff auf das System voraus. Sie ist typischerweise ein zweiter Schritt nach einem bereits erfolgten Einbruch. Ein gehärteter Zugang senkt das Risiko deutlich.

Warum ist eine lokale Lücke auf dem Backup-Server so kritisch?

Weil der Backup-Server das letzte Sicherungsnetz ist. Wer dort root-Rechte erlangt, kann Sicherungen einsehen, verändern oder löschen und so eine Wiederherstellung nach einem Angriff verhindern.

Fazit

Die Veeam-Updater-Schwachstelle CVE-2026-56844 verdient Aufmerksamkeit, aber verfallen Sie nicht in Hektik. Die Lücke ist nicht aus dem Internet ausnutzbar, und der Hersteller verteilt die Korrektur in vielen Umgebungen automatisch. Wer die betroffenen Appliances im Blick hat, die Updater-Version 12.3.0.65 bestätigt und den lokalen Zugriff sauber einschränkt, hat das Wesentliche erledigt.

Entscheidend bleibt: Gerade der Backup-Server braucht besonderen Schutz – er ist das System, auf das im Ernstfall alles ankommt.

Weitere interessante Beiträge

mars-News

AOK-Firmenlauf in Göppingen 2026 - mars läuft mit!

9. Juli 2026

Zum Blogbeitrag

IT-News

OWAReaper: Half-Click-Exploit übernimmt Exchange-Postfächer

31. Juli 2026

Zum Blogbeitrag

IT-News

Kritische Windows-Server-Lücke im Netlogon-Code: CVE-2026-41089

1. Juni 2026

Zum Blogbeitrag

Fanden Sie den Blogbeitrag hilfreich und interessant?

Vielen Dank für Ihre Rückmeldung!

Der Beitrag Veeam Sicherheitslücke: Veeam-Updater ermöglicht Rechteausweitung erschien zuerst auf mars solutions GmbH.

Windows Defender Sicherheitslücke: Microsoft patcht RoguePlanet-Zero-Day nach

Technischer Support — Wed, 15 Jul 2026 07:11:23 +0000

Windows Defender Sicherheitslücke: Microsoft patcht RoguePlanet Zero-Day nach

Die Windows Defender Sicherheitslücke „RoguePlanet“ (CVE-2026-50656) beschäftigt Microsoft inzwischen den zweiten Monat in Folge. Der öffentlich verfügbare Zero-Day-Exploit erlaubt es Angreifern, sich auf vollständig gepatchten Windows-10- und Windows-11-Systemen SYSTEM-Rechte zu verschaffen – die höchste Berechtigungsstufe unter Windows.

Am 8. Juli 2026 hat Microsoft eine aktualisierte Version der Defender-Scan-Engine veröffentlicht, die die Lücke schließen soll, diese wird als nachgelegter Patch bezeichnet, nachdem eine erste Korrektur offenbar nicht ausreichte.

Warum die Schwachstelle besonders unangenehm ist, wie Sie den Patch-Stand Ihrer Systeme prüfen und welche offenen Punkte es rund um das Update gibt, lesen Sie hier.

Das Wichtigste in Kürze

RoguePlanet (CVE-2026-50656, CVSS 7,8) ist eine Elevation-of-Privilege-Schwachstelle in der Malware Protection Engine des Microsoft Defender.
Ein öffentlich verfügbarer Exploit hebt die Rechte eines Standardbenutzers per Race Condition auf NT AUTHORITY\SYSTEM an – unabhängig davon, ob der Echtzeitschutz aktiv ist.
Betroffen sind Windows 10 und Windows 11 mit aktivem Microsoft Defender, auch mit vollständigem Juni-Patchstand.
Geschützt sind Systeme ab Engine-Version 1.1.26060.3008, die Verteilung erfolgt automatisch über die Update-Kanäle des Defenders.
Der Entdecker meldet bereits ein neues Problem im gepatchten Modul – Microsoft hat sich dazu bislang nicht geäußert (Stand: 15. Juli 2026).

Was hinter RoguePlanet steckt

Veröffentlicht wurde der Exploit Anfang Juni 2026 am Tag des Juni-Patchdays. Ein anonymer IT-Sicherheitsforscher legt seit März 2026 in kurzen Abständen Zero-Day-Schwachstellen in Microsoft-Produkten offen. Hintergrund ist ein öffentlich ausgetragener Streit mit Microsoft über den Umgang mit Bug-Bounty-Meldungen. Statt Schwachstellen koordiniert zu melden, veröffentlicht Nightmare Eclipse funktionsfähige Proof-of-Concept-Exploits samt Quellcode direkt im Netz. Drei der zuvor geleakten Lücken hat Microsoft mit dem Juni-Patchday geschlossen – RoguePlanet folgte unmittelbar danach als nächste offene Baustelle.

Windows Defender Sicherheitslücke im Detail

CVSS 7,8

Risikobewertung der Lücke: „hoch“

CWE-59

Fehlerhafte Link-Auflösung, kombiniert mit einer Race Condition

SYSTEM

Höchste Berechtigungsstufe unter Windows als Ziel des Exploits

Technisch handelt es sich bei der Windows Defender Sicherheitslücke „RoguePlanet“ CVE-2026-50656 um eine Elevation-of-Privilege-Schwachstelle (Rechteausweitung) in der Malware Protection Engine (mpengine.dll), dem zentralen Scan-Modul des Microsoft Defender.

Bewertet wird die Lücke mit einem CVSS-Score von 7,8 („hoch“). Ursache ist eine fehlerhafte Auflösung von Dateiverknüpfungen vor dem Dateizugriff (CWE-59) in Kombination mit einer Race Condition: Der Exploit nutzt ein enges Zeitfenster aus, in dem die mit höchsten Rechten laufende Scan-Engine auf Dateien zugreift, und startet darüber eine Eingabeaufforderung mit SYSTEM-Rechten.

Wichtige Hinweise

Ein Angreifer, der bereits ein normales Benutzerkonto kontrolliert – etwa nach einer erfolgreichen Phishing-Attacke – kann durch die IT-Sicherheitslücke in Windows Defender die vollständige Kontrolle über das System übernehmen. Administratorrechte sind dafür nicht erforderlich, eine Benutzerinteraktion ebenfalls nicht. Da der Angriff auf einer Race Condition beruht, gelingt er nicht bei jedem Versuch – laut dem Entdecker der IT-Sicherheitslücke liegt die Erfolgsquote je nach System jedoch teils bei 100 Prozent.

Der Exploit funktioniert unabhängig davon, ob der Echtzeitschutz aktiviert ist. Versuche, den Proof-of-Concept über Signaturen zu blockieren, ließen sich nach Angaben des Forschers durch kleine Anpassungen am Code umgehen – ein zuverlässiger Schutz war damit erst mit dem Patch der Engine selbst möglich.

Diese Systeme sind betroffen

Verwundbar sind Windows 10 und Windows 11 mit aktivem Microsoft Defender – auch dann, wenn alle aktuellen Windows-Updates installiert sind.

Der IT-Sicherheitsforscher testete den Exploit nach eigenen Angaben unter anderem auf Systemen mit vollständigem Juni-Patchstand. Kommt dagegen ein Virenschutz eines Drittherstellers zum Einsatz und ist der Defender dadurch deaktiviert, läuft die verwundbare Scan-Engine nicht – dieser Angriffsweg scheidet dann aus. Microsoft stufte die Ausnutzungswahrscheinlichkeit im Advisory von Beginn an als „Exploitation More Likely“ ein. Mehrere Sicherheitsanbieter berichten inzwischen über aktive Angriffe auf Basis der öffentlich verfügbaren Exploits.

Verwundbar

Nicht betroffen

Engine-Version prüfen: So gehen Sie vor

Anders als klassische Windows-Patches wird die Korrektur nicht über ein kumulatives Update mit KB-Nummer verteilt, sondern über die automatischen Update-Mechanismen des Defenders:

Die Malware Protection Engine aktualisiert sich zusammen mit den Sicherheitsinformationen (Definitionsupdates) in der Regel ohne weiteres Zutun.

Geschützt sind Systeme ab Engine-Version 1.1.26060.3008, Versionen bis einschließlich 1.1.26050.11 gelten als verwundbar. So prüfen Sie den Stand auf einem einzelnen System:

Windows-Sicherheit öffnen (Start-Menü, „Sicherheit“ eingeben).

Unter „Viren- & Bedrohungsschutz“ im Bereich „Updates für Viren- & Bedrohungsschutz“ nach Updates suchen.

In den Einstellungen der Windows-Sicherheit den Punkt „Info“ öffnen.

Die Zeile „Modulversion“ (Engine-Version) kontrollieren: 1.1.26060.3008 oder höher bedeutet geschützt.

In verwalteten Umgebungen lässt sich der Stand zentral erheben – etwa per PowerShell mit Get-MpComputerStatus (Feld AMEngineVersion) oder über das Reporting von Microsoft Intune, Configuration Manager bzw. WSUS.

PowerShell – Engine-Version zentral abfragen

# geschützt ab Engine-Version 1.1.26060.3008
Get-MpComputerStatus | Select-Object AMEngineVersion

Wichtig für IT-Admins

Wer Definitionsupdates über WSUS oder andere Kanäle verzögert oder manuell freigibt, sollte die Freigabe der neuen Engine jetzt priorisieren.

Kritik am nachgelegten Patch

Kurz nach Veröffentlichung des Updates wurde bekannt., dass die gepatchte Engine beim Verarbeiten von Zone.Identifier-Metadaten keine Größenbegrenzung im Zwischenspeicher durchsetzen soll. Dahinter stehen sogenannte Alternate Data Streams (ADS) – kleine Zusatzinformationen, die Windows an Dateien anhängt, die aus dem Netz geladen wurden. Ein präparierter SMB-Server könnte demnach übergroße ADS-Einträge ausliefern und den Datenträger eines Zielsystems nach und nach vollständig füllen. Die Folgen einer vollen Systempartition sind bekannt: fehlschlagende Updates, abstürzende Anwendungen, im ungünstigsten Fall Startprobleme.

Wichtig zu wissen

Der beschriebene Angriff setzt Netzwerkzugriff und spezielle Rahmenbedingungen voraus und ist deutlich schwerer auszunutzen als die ursprüngliche Rechteausweitung. Microsoft hat sich zu dem gemeldeten Verhalten bislang nicht geäußert (Stand: 15. Juli 2026), das offizielle Advisory behandelt ausschließlich die Rechteausweitung. Ein Grund, auf den Patch zu verzichten, ist die Meldung ausdrücklich nicht – ein ungepatchtes System bleibt das erheblich größere Risiko. Mit einem weiteren Engine-Update ist zu rechnen.

To Do's für IT-Admins

Engine-Version flächendeckend prüfen (mindestens 1.1.26060.3008) – nicht nur stichprobenartig, sondern über zentrales Reporting.
Sicherstellen, dass Definitions- und Engine-Updates automatisch fließen; WSUS-/Intune-Freigaben kontrollieren.
Systeme mit eingefrorenen oder deaktivierten Defender-Updates identifizieren – etwa Golden Images, VDI-Templates oder selten laufende Geräte.
Festplattenauslastung auf exponierten Systemen und Fileservern im Monitoring behalten (Stichwort ADS-Cache).
SMB-Verkehr in Richtung Internet weiterhin blockieren und die interne Netzwerksegmentierung prüfen.
Das MSRC-Advisory zu CVE-2026-50656 auf Folge-Updates beobachten.

Windows Defender Sicherheitslücke: Einordnung für Entscheider

Der Fall zeigt zwei Dinge. Erstens: Auch Sicherheitssoftware selbst ist Angriffsfläche. Gerade weil ein Virenschutz mit höchsten Rechten tief im System arbeitet, wiegen Fehler in diesem Bereich besonders schwer. Zweitens: Patch-Management endet nicht beim monatlichen Patchday. Komponenten wie die Defender-Engine aktualisieren sich über eigene Kanäle – wer den Sicherheitsstand nur anhand installierter KB-Nummern bewertet, übersieht solche Updates systematisch.

Eine akute Gefahr für jedes Unternehmen ist RoguePlanet dabei nicht automatisch: Angreifer benötigen zunächst Zugriff auf ein Benutzerkonto, etwa über Phishing oder eingeschleuste Schadsoftware. In Kombination mit einem solchen Erstzugriff wird aus der Lücke jedoch ein direkter Weg zur vollständigen Systemübernahme. Funktionierende Update-Prozesse, ein Monitoring der Sicherheitskomponenten und das Prinzip minimaler Berechtigungen bleiben damit die wirksamsten Hebel – unabhängig vom konkreten Einzelfall.

Fazit

Microsoft hat auf die Windows Defender Sicherheitslücke RoguePlanet reagiert und verteilt den Schutz automatisch über die Malware Protection Engine 1.1.26060.3008. Auf den meisten Systemen geschieht das unbemerkt – blind verlassen sollte man sich darauf nicht.

Eine kurze Kontrolle der Modulversion schafft Gewissheit; in Unternehmensumgebungen gehört sie jetzt auf die Checkliste. Offen bleibt, wie Microsoft auf die gemeldete Schwäche im Cache-Verhalten der neuen Engine reagiert – das Thema Defender-Updates dürfte IT-Verantwortliche also noch eine Weile begleiten.

Weitere interessante Beiträge

mars-News

Rückblick auf das 2. Managed NMS Symposium 2026

19. Juni 2026

Zum Blogbeitrag

IT-News

OWAReaper: Half-Click-Exploit übernimmt Exchange-Postfächer

31. Juli 2026

Zum Blogbeitrag

IT-News

Windows 11-Update KB5094126: Bugs in Office, File Explorer und Papierkorb

24. Juni 2026

Zum Blogbeitrag

Fanden Sie den Blogbeitrag hilfreich und interessant?

Vielen Dank für Ihre Rückmeldung!

Der Beitrag Windows Defender Sicherheitslücke: Microsoft patcht RoguePlanet-Zero-Day nach erschien zuerst auf mars solutions GmbH.

AOK-Firmenlauf in Göppingen 2026 – mars läuft mit!

Neli Hegenloh — Thu, 09 Jul 2026 08:10:27 +0000

AOK-Firmenlauf in Göppingen 2026 – mars läuft mit!

Juli 9, 2026
10:10
Neli Hegenloh

Am Mittwoch, 8. Juli 2026, war es wieder so weit: Der 12. AOK Firmenlauf Göppingen startete um 18:30 Uhr im Dr.-Heinrich-Zeller-Stadion – und mars war wieder mit seinem Team am Start.

Der AOK-Firmenlauf gehört mittlerweile zu den festen Terminen im mars-Jahreskalender.

Auf der 5-Kilometer-Strecke durch das Göppinger Oberholz und beim anschließenden Zieleinlauf im FrischAUF-Stadion stand für unser Team vor allem eines im Vordergrund: der gemeinsame Spaß.

Die Veranstaltung war in diesem Jahr wieder gut besucht: Mit 2.300 angemeldeten Läuferinnen und Läufern war der Firmenlauf bereits im Vorfeld ausgebucht. Organisiert wurde das Event von BW-Running in Kooperation mit der AOK Baden-Württemberg.

Es war ein sportlicher Abend mit vielen bekannten Gesichtern aus der Göppinger Unternehmenslandschaft. Genau wie im Arbeitsalltag gilt auch beim Firmenlauf: Zusammenhalt bringt uns ans Ziel.

Danke an alle, die mit uns gelaufen sind – bis zum nächsten Mal!

Weitere Informationen und Ergebnisse zum AOK Firmenlauf Göppingen unter goeppingen.bw-running.de.

Weitere interessante Beiträge

IT-News

Sicherheitsupdate für Veeam Backup & Replication: Kritische Systeme zeitnah aktualisieren

27. Mai 2026

Zum Blogbeitrag

mars-News

Rückblick auf das 2. Managed NMS Symposium 2026

19. Juni 2026

Zum Blogbeitrag

IT-News

Windows Defender Sicherheitslücke: Microsoft patcht RoguePlanet-Zero-Day nach

15. Juli 2026

Zum Blogbeitrag

Fanden Sie den Blogbeitrag hilfreich und interessant?

Vielen Dank für Ihre Rückmeldung!

Der Beitrag AOK-Firmenlauf in Göppingen 2026 – mars läuft mit! erschien zuerst auf mars solutions GmbH.

Password Spraying: Wenn Microsoft 365 zur Zielscheibe wird

Technischer Support — Wed, 01 Jul 2026 09:12:50 +0000

Password Spraying: Wenn Microsoft 365 zur Zielscheibe wird

Technischer Support
Juli 1, 2026
11:12

Zwischen dem 12. und 26. Juni 2026 registrierten Sicherheitsforscher mehr als 81 Millionen Anmeldeversuche gegen Microsoft-365-Umgebungen mittels Passwort Spraying.

Am Ende der zweiwöchigen Angriffswelle standen 78 gehackte Benutzerkonten in 64 Organisationen. Bemerkenswert ist dabei weniger die schiere Zahl der Versuche, sondern der Weg, auf dem die Angreifer erfolgreich waren: Password Spraying in Kombination mit einer veralteten Anmeldemethode, die viele Unternehmen unbewusst noch offen haben.

Der Fall zeigt exemplarisch, warum Passwort-Sicherheit und eine korrekt konfigurierte Mehrfaktor-Authentifizierung (MFA) auch 2026 keine Selbstverständlichkeit sind – selbst dort, wo entsprechende Richtlinien auf dem Papier längst bestehen. Was Sie alles über Passwort Spraying wissen sollten und wie Sie sich und Ihr Unternehmen nachhaltig schützen können, erfahren Sie hier.

So lief der Password Spraying-Angriff ab

Das IT-Sicherheitsunternehmen Huntress beobachtete die Passwort Spraying-Angriffe bei einer Vielzahl eigener Kundenumgebungen. Die Angreifer nutzten kein Passwort-Erraten im klassischen Sinn, sondern spielten zuvor aus Datenlecks bekannte Benutzername-Passwort-Kombinationen automatisiert gegen Microsoft-365-Konten durch. Klassisches Password Spraying setzt dabei bewusst auf niedrige Versuchszahlen pro Konto, um automatisierte Kontosperren zu umgehen – im vorliegenden Fall sorgte allein die schiere Masse an Zielkonten für das hohe Gesamtvolumen.

Für die Anmeldeversuche kam die Azure Command Line Interface (Azure CLI) zum Einsatz, ein reguläres Verwaltungswerkzeug für Microsofts Cloud-Plattform. Sobald eine gültige Kombination gefunden wurde, meldeten sich die Angreifer über den OAuth-Ablauf Resource Owner Password Credentials (ROPC) an.

Der Passwort Spraying-Angriff in vier Schritten

1

Geleakte Zugangsdaten sammeln

Bekannte Benutzername-Passwort-Kombinationen aus früheren Datenlecks werden automatisiert bereitgestellt.

2

Automatisiertes Durchprobieren

Über die Azure CLI werden die Kombinationen gegen Microsoft-365-Konten getestet – mit niedriger Frequenz, um Sperren zu umgehen.

3

Über ROPC anmelden

Bei einem Treffer erfolgt die Anmeldung über den OAuth-Flow ROPC – ganz ohne interaktiven Login-Dialog.

4

Zugriffstoken erhalten

Der Token-Endpunkt stellt direkt ein Zugriffstoken aus. Ein zweiter Faktor wird dabei nie abgefragt.

Warum Password Spraying hier funktionierte

Auf den ersten Blick wirkt eine Erfolgsquote von 78 gehackten Konten bei 81 Millionen Versuchen verschwindend gering. Der eigentliche Befund liegt jedoch woanders: Ein erheblicher Teil der betroffenen Organisationen hatte MFA über Conditional-Access-Richtlinien (CAP) bereits aktiviert.
Trotzdem griff der Schutz nicht!

Der Grund liegt im verwendeten ROPC-Flow. Dieser OAuth-2.0-Mechanismus übermittelt Benutzername und Passwort direkt an den Token-Endpunkt eines Tenants und stellt bei Übereinstimmung unmittelbar ein Zugriffstoken aus.
Ein interaktiver Anmeldedialog, über den normalerweise die Abfrage eines zweiten Faktors erfolgt, findet dabei nicht statt.
Conditional-Access-Richtlinien greifen üblicherweise am Autorisierungs-Endpunkt, an dem auch die MFA-Abfrage ausgelöst wird.
Da ROPC diesen Endpunkt umgeht, kann eine an sich korrekt aktivierte MFA-Richtlinie wirkungslos bleiben, wenn sie nicht auch explizit alle Client-App-Typen und Authentifizierungsflows abdeckt.

ROPC umgeht die MFA-Abfrage

Microsoft empfiehlt daher in der eigenen Dokumentation, den ROPC-Flow zu vermeiden, sofern keine zwingenden technischen Gründe vorliegen.
Im aktuellen OAuth-2.1-Standard gilt der Grant-Type zudem als veraltet.

Typische Lücken in bestehenden Richtlinien

Huntress dokumentierte bei den betroffenen Organisationen mehrere wiederkehrende Konfigurationsmuster, die den Angriff begünstigten:

MFA nur für bestimmte Cloud-Apps – nicht für „Alle Cloud-Apps“, wodurch Azure-CLI-Anmeldungen außen vor blieben.
MFA nur für ausgewählte Benutzergruppen – etwa nur Administratorkonten, während reguläre Konten ungeschützt blieben.
MFA nur bei nicht vertrauenswürdigen Standorten – fälschlich als vertrauenswürdig eingestufte IPs umgingen die Abfrage.
Richtlinien im Report-only-Modus – die Regel existierte, wurde jedoch nie tatsächlich durchgesetzt.
Keine MFA-Richtlinie vorhanden – bei einem Teil der Organisationen fehlte eine entsprechende Regel komplett.

Diese Muster zeigen:

Das Vorhandensein von MFA allein sagt wenig über die tatsächliche Schutzwirkung aus.
Entscheidend ist die konkrete Abdeckung von Benutzern, Anwendungen und Authentifizierungsprotokollen in der jeweiligen Richtlinie.

Zahlen, Daten, Fakten

Kurz und knapp die Zahlen, Daten und Fakten der Passwort Spraying-Kampagne im Überblick:

Anmeldeversuche in 2 Wochen

0 Mio.

gehackte Konten

mehr Angriffe in 6 Monaten

0 -fach

Fehlversuche pro Tenant/Monat (Ø)

Password Spraying als wachsender Trend

Huntress ordnet die aktuelle Angriffswelle in einen größeren Trend ein. Nach eigenen Angaben ist das Volumen an Password Spraying-Angriffen über alle Kundenumgebungen hinweg in den vergangenen sechs Monaten um mehr als das 155-Fache gestiegen.

Die 81 Millionen Versuche aus dieser Angriffswelle sind damit weniger ein Ausreißer als ein Beleg für ein branchenweit zunehmendes Hintergrundrauschen an automatisierten Anmeldeversuchen. Die Zielauswahl folgte dabei keinem erkennbaren Branchenmuster – ausschlaggebend war allein, ob eine passende Kombination aus geleakten Zugangsdaten vorlag.

Empfehlungen für IT-Admins

Aus dem beschriebenen Password-Spraying-Vorfall lassen sich konkrete, sofort umsetzbare Prüfpunkte ableiten:

Conditional-Access-Richtlinien vollständig konfigurieren – „Alle Benutzer“, „Alle Cloud-Apps“ und „Alle Client-App-Typen“ abdecken; den „What-If“-Simulator im Entra-Admin-Center nutzen.
Legacy-Authentifizierung und ROPC einschränken oder blockieren – veraltete, nicht-interaktive Flows deaktivieren; Azure CLI nur für klar abgegrenzte Admin-Konten zulassen.
Anmeldeprotokolle auf Spray-Muster auswerten – gehäufte Fehlversuche, ungewöhnliche Azure-CLI-Logins und auffällige Autonome Systeme (ASN) im Blick behalten.
Zugangsdaten mit Programmzugriff rotieren – insbesondere bei möglicher Betroffenheit durch frühere Datenlecks.
SIEM-Alarmierung für ROPC-Tokenausstellungen einrichten – jede verbleibende ROPC-Anmeldung als Alarm behandeln.

Bedeutung für Geschäftsführung und Entscheider

Für Entscheider ohne tiefes technisches Detailwissen lässt sich der Vorfall auf einen zentralen Punkt reduzieren:
Eine aktivierte Mehrfaktor-Authentifizierung ist kein Garant für Sicherheit, wenn sie nicht lückenlos auf alle Zugriffswege angewendet wird.

Die Kosten eines erfolgreichen Kontenübergriffs beschränken sich dabei selten auf das einzelne Postfach. Ein per ROPC erlangtes Zugriffstoken kann je nach Berechtigungsumfang des betroffenen Kontos weitreichenden Zugriff auf eine gesamte Microsoft-365- oder Azure-Umgebung ermöglichen.

Eine regelmäßige, unabhängige Überprüfung der eigenen IT-Sicherheitsrichtlinien gehört damit zu den sinnvollsten Investitionen in die IT-Sicherheit.

FAQ zu Password Spraying

Was ist Password Spraying?

Beim Password Spraying probieren Angreifer wenige, häufig genutzte Passwörter automatisiert gegen viele Konten – mit niedriger Versuchszahl pro Konto, um Kontosperren zu umgehen.

Warum schützt MFA in diesem Fall nicht?

Der genutzte ROPC-Flow übermittelt die Zugangsdaten direkt an den Token-Endpunkt und umgeht den interaktiven Login-Dialog, an dem sonst der zweite Faktor abgefragt wird.

Was ist der ROPC-Flow?

Resource Owner Password Credentials ist ein OAuth-Ablauf, der Benutzername und Passwort direkt gegen ein Zugriffstoken eintauscht. Er ist nicht mit MFA oder SSO kompatibel und gilt als veraltet.

Wie sichere ich Microsoft 365 dagegen ab?

Conditional-Access-Richtlinien vollständig konfigurieren, Legacy- und ROPC-Flows blockieren, Anmeldeprotokolle auswerten und ROPC-Tokenausstellungen per SIEM alarmieren.

Fazit

Die Angriffswelle gegen Microsoft-365-Konten macht deutlich, dass Password Spraying nach wie vor eine wirksame Angriffstechnik ist, wenn Authentifizierungsrichtlinien Lücken aufweisen.

Nicht die Menge der Anmeldeversuche entscheidet über den Erfolg eines Angriffs, sondern die Frage, ob wirklich jeder Authentifizierungsweg durch MFA abgedeckt ist. Unternehmen, die ihre Conditional-Access-Richtlinien auf Vollständigkeit prüfen, veraltete Anmeldeflows wie ROPC konsequent einschränken und ihre Anmeldeprotokolle aktiv auswerten, reduzieren das Risiko erheblich, selbst zu den Betroffenen zu zählen.

Weitere interessante Beiträge

IT-News

Secure Boot-Zertifikate 2026: Stichtag 24. Juni für Windows-Systeme

23. Juni 2026

Zum Blogbeitrag

IT-News

Microsoft Exchange Zero-Day CVE-2026-42897: Warum Unternehmen jetzt handeln müssen

20. Mai 2026

Zum Blogbeitrag

IT-News

Teams-Phishing ohne Fake-Login: Consent-Phishing

11. August 2026

Zum Blogbeitrag

Fanden Sie den Blogbeitrag hilfreich und interessant?

Vielen Dank für Ihre Rückmeldung!

Der Beitrag Password Spraying: Wenn Microsoft 365 zur Zielscheibe wird erschien zuerst auf mars solutions GmbH.

Windows 11-Update KB5094126: Bugs in Office, File Explorer und Papierkorb

Technischer Support — Wed, 24 Jun 2026 07:00:00 +0000

Windows 11-Update KB5094126: Bugs in Office, File Explorer und Papierkorb

Juni 24, 2026
09:00

Die Bugs von KB5094126 im Überblick

Nach den Secure Boot-Problemen folgt die zweite Welle:
KB5094126, das kumulative Windows 11-Update vom Patchday am 9. Juni 2026, sorgt für weitere, von Microsoft inzwischen offiziell bestätigte Fehler. Betroffen sind der Start von Microsoft Office aus Drittsoftware, der Löschdialog des Papierkorbs sowie der Zugriff auf OneDrive im Datei-Explorer.

Gut zu wissen

Durch keinen der bestätigten Fehler droht ein Datenverlust. Der Papierkorb-Bug ist rein kosmetisch, OneDrive-Daten bleiben über den direkten Pfad erreichbar und Office selbst funktioniert weiterhin – betroffen ist nur der automatisierte Aufruf aus Drittprogrammen.

Office startet nicht aus Drittsoftware

Der für Unternehmen gravierendste Fehler betrifft die OLE-Automation – die Schnittstelle, über die andere Programme Word, Excel oder PowerPoint im Hintergrund ansteuern. Nach der Installation vom KB5094126 können bestimmte Drittanbieter-Anwendungen die Office-Programme nicht mehr starten oder Dokumente nicht mehr öffnen – teils ohne Fehlermeldung.

Workaround: das Dokument bzw. die Office-Anwendung direkt öffnen, statt den Umweg über die Fachsoftware zu nehmen.

Papierkorb zeigt kryptische Dateinamen

Löschen Sie ein einzelnes Element endgültig aus dem Papierkorb, zeigt der Bestätigungsdialog nicht mehr den echten Dateinamen, sondern den internen Papierkorb-Code – etwa $R9K06N2.docx statt Bericht.docx. Ursache ist eine Sicherheitsverschärfung des Juni-Patchdays. Der Fehler ist rein kosmetisch: Es wird die korrekte Datei gelöscht, und beim Wiederherstellen erhält sie ihren Originalnamen zurück. Microsoft korrigiert den Punkt mit dem Patchday am 14. Juli 2026.

Welche Systeme sind betroffen

Produkt	Betroffene Versionen
Windows 11	23H2, 24H2, 25H2, 26H1
Windows 10	22H2 inkl. LTSC 2019 / 2021
Windows Server	2012 bis 2025

Der Papierkorb-Fehler hängt nicht an einem einzelnen Build, sondern an der gemeinsamen Sicherheitsarchitektur des Juni-Patchdays.

Die Empfehlung: KB5094126 kontrolliert ausrollen

Pilotgruppe zuerst: Windows 11-Update KB5094126 auf einer kleinen, repräsentativen Gerätegruppe testen.

Office-Fachsoftware prüfen: Workflows mit OLE-Automation gezielt durchtesten.

Helpdesk briefen: Anwender informieren, dass kryptische Namen kein Datenverlust sind.

OneDrive kontrollieren: Geräte mit lokalem Admin und deaktivierter UAC prüfen.

Juli-Patchday einplanen: Papierkorb-Fix kommt am 14. Juli 2026.

Was IT-Admins wissen sollten

Update gestaffelt statt flächendeckend ausrollen
EFI-Partition und BIOS/UEFI der Pilotgeräte prüfen
BitLocker-Wiederherstellungsschlüssel zentral sichern
Office-abhängige Drittsoftware vor dem Rollout testen
Workarounds im Support-Prozess dokumentieren
Enterprise-Support für den Papierkorb-Workaround nutzen

Nützliche Befehle

Das Windows 11-Update KB5094126 behandelt die Datei desktop.ini strenger, wodurch benutzerdefinierte Ordnersymbole verschwinden können.
Diese PowerShell-Befehle helfen bei der Diagnose und Korrektur:

# Ordnersymbole nach dem Update wieder freigeben
Unblock-File -Path "C:\Pfad\zum\Ordner\desktop.ini"

# Secure-Boot-Status prüfen
Confirm-SecureBootUEFI

FAQ zu KB5094126

Gehen durch den Papierkorb-Bug Daten verloren?

Nein. Der Fehler ist rein kosmetisch. Es wird die korrekte Datei gelöscht, und beim Wiederherstellen erhält sie ihren ursprünglichen Namen zurück.

Warum startet Office nicht mehr aus unserer Fachsoftware?

KB5094126 verändert das Verhalten der OLE-Automation. Programme, die Word, Excel oder PowerPoint im Hintergrund ansteuern, können diese teils nicht mehr starten. Abhilfe: das Dokument direkt öffnen.

Welche Systeme sind betroffen?

Windows 11 (23H2–26H1), Windows 10 22H2 inklusive LTSC 2019/2021 sowie Windows Server 2012 bis 2025.

Sollten wir das Update trotzdem installieren?

Ja. KB5094126 schließt kritische Sicherheitslücken. Empfohlen wird ein gestaffelter Rollout mit vorheriger Prüfung auf einer Pilotgruppe.

Fazit

Sicher patchen. Updates kontrolliert ausrollen.
KB5094126 zeigt erneut, dass Updates für die Verlässlichkeit im Tagesgeschäft genauso entscheidend sind wie für die Sicherheit.
Datenverlust droht durch keinen der bestätigten Fehler.
Wer Office aus Drittprogrammen automatisiert, sollte vor dem Rollout testen – ein abgestufter Rollout mit klaren Testszenarien ist hierfür empfehlenswert.

Weitere interessante Beiträge

IT-News

Veeam Sicherheitslücke: Veeam-Updater ermöglicht Rechteausweitung

17. Juli 2026

Zum Blogbeitrag

IT-News

Microsoft-365-Preiserhöhung zum 1. Juli 2026

28. Mai 2026

Zum Blogbeitrag

IT-News

Windows 11 Juni-Update Boot-Probleme

15. Juni 2026

Zum Blogbeitrag

Fanden Sie den Blogbeitrag hilfreich und interessant?

Vielen Dank für Ihre Rückmeldung!

Der Beitrag Windows 11-Update KB5094126: Bugs in Office, File Explorer und Papierkorb erschien zuerst auf mars solutions GmbH.

Secure Boot-Zertifikate 2026: Stichtag 24. Juni für Windows-Systeme

Technischer Support — Tue, 23 Jun 2026 08:22:00 +0000

Secure Boot-Zertifikate 2026: Stichtag 24. Juni für Windows-Systeme

Juni 23, 2026
10:22

Die Secure Boot-Zertifikate aus dem Jahr 2011 laufen ab Juni 2026 aus – beginnend mit dem 24. Juni 2026.
Für die meisten Privatgeräte ist das ein Nicht-Ereignis, weil Microsoft die Erneuerung im Hintergrund übernimmt.
Für verwaltete Umgebungen in Unternehmen, Server und ältere Hardware ist es dagegen eine planbare, aber nicht triviale Migrationsaufgabe.

Wichtige Fakten zu Secure Boot

Die 2011er-Zertifikate laufen ab Juni 2026 aus, erster Stichtag ist der 24. Juni 2026 (KEK CA 2011).
Geräte starten weiterhin normal und erhalten weiterhin reguläre Windows-Updates.
Es entfallen neue Schutzmechanismen für den frühen Boot-Vorgang.
Ersatz ist eine 2023er-CA-Kette, gültig bis 2038.
Clients werden weitgehend automatisch versorgt – Windows Server nur durch manuelles Handeln.

Was ist Secure Boot – und warum laufen Zertifikate ab?

Secure Boot ist eine Funktion der UEFI-Firmware und prüft schon vor dem Start des Betriebssystems, ob Bootloader und frühe Boot-Komponenten von einer vertrauenswürdigen Stelle signiert wurden. Das Vertrauen stützt sich auf Zertifizierungsstellen (CAs), deren Schlüssel in den UEFI-Variablen KEK und DB hinterlegt sind.

Wie jedes Zertifikat haben auch diese CAs ein Ablaufdatum. Die 2011 ausgestellten Microsoft-Zertifikate erreichen 2026 ihr Lebensende – ein regulärer Lifecycle-Vorgang, der zugleich die Secure-Boot-Härtung seit der BlackLotus-Lücke (CVE-2023-24932) fortführt.

Welche Zertifikate laufen genau ab?

Betroffen sind drei Microsoft-Zertifikate mit unterschiedlichen Aufgaben:

Zertifikat (2011)	Rolle	Ablauf
Microsoft Corporation KEK CA 2011	Key Exchange Key (KEK)	24. Juni 2026
Microsoft Corporation UEFI CA 2011	Drittanbieter-Bootloader & Option ROMs	Juni 2026
Microsoft Windows Production PCA 2011	Windows-Bootloader (in der DB)	Oktober 2026

An ihre Stelle tritt die erneuerte 2023er-Kette:
Microsoft Corporation KEK 2K CA 2023, Windows UEFI CA 2023 (Windows Boot Manager),
Microsoft UEFI CA 2023 (Drittanbieter-Bootloader) sowie Microsoft Option ROM UEFI CA 2023.

Die einzelne Drittanbieter-CA wurde dabei bewusst in zwei 2023er-CAs aufgeteilt. Die neuen Zertifikate sind bis 2038 gültig.

Was passiert, wenn man nichts tut?

Kein Gerät bleibt am Stichtag stehen.
Systeme mit abgelaufenen 2011er-Zertifikaten booten weiterhin, und reguläre Windows-Updates werden weiter installiert. Es entfallen lediglich neue Schutzmechanismen für den frühen Boot-Vorgang (Windows Boot Manager, DB/DBX-Sperrlisten, Boot-Level-Fixes). Mit jeder künftigen Bedrohung sinkt die Schutzwirkung eines nicht migrierten Geräts also schrittweise – kein akuter Ausfall, sondern eine schleichend wachsende Lücke.

Wie kommen die neuen Zertifikate auf die Geräte?

Windows-Clients

Viele PCs ab 2024 bringen die 2023er-Zertifikate bereits mit. Übrige erhalten sie über monatliche Windows-Updates (Controlled Feature Rollout) – standardmäßig aktiv. Voraussetzung: Updates ab dem 11.11.2025.

Windows Server

Erhält die Zertifikate nicht automatisch. Administratoren stoßen die Aktualisierung manuell an – per Registry, Gruppenrichtlinie oder Virtualisierungs-plattform.

Linux / VMs / Cloud

Dual-signierte Shims (2011 + 2023) halten Systeme bootfähig. Bei Shielded-/Trusted-Launch-VMs muss die virtuelle Firmware die neuen Zertifikate kennen. TPM-PCR-Werte ändern sich.

Wie prüft man den Status der Geräte?

Vor jedem Rollout steht die Bestandsaufnahme. Diese Wege liefern verlässliche Aussagen:

Registry: UEFICA2023Status - NotStarted / InProgress / Updated
Ereignisanzeige: Event ID 1808 = Erfolg, 1801 = nicht angewendet
PowerShell: Confirm-SecureBootUEFI und Get-SecureBootUEFI
Flottenweit: Windows Autopatch Secure-Boot-Statusbericht (Intune)

PowerShell

# Zertifikatsstatus auslesen (PowerShell)
Get-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing' `
  -Name UEFICA2023Status | Select-Object UEFICA2023Status

Wie rollt man die Aktualisierung der Secure Boot-Zertifikate aus?

Firmware vorbereiten

Aktuelles BIOS/UEFI des Herstellers einspielen und BitLocker für 1-2 Neustarts aussetzen.

Rollout auslösen

Registry-Wert AvailableUpdates auf 0x5944 setzen.

Aufgabe starten

Geplante Aufgabe Secure-Boot-Update ausführen, statt auf den 12-Stunden-Zyklus zu warten.

Abschluss prüfen

Zwei Neustarts durchführen; Erfolg über UEFICA2023Status = „Updated“ und Event ID 1808 verifizieren.

CMD / PowerShell

REM Rollout per Registry auslösen
reg add HKLM\SYSTEM\CurrentControlSet\Control\SecureBoot ^
  /v AvailableUpdates /t REG_DWORD /d 0x5944 /f

REM Aufgabe sofort starten (PowerShell)
Start-ScheduledTask -TaskName "\Microsoft\Windows\PI\Secure-Boot-Update"

Zwei Neustarts sind normal und kein Fehler.
Die Verteilung ist auch per Gruppenrichtlinie („Enable Secure Boot certificate deployment“), Microsoft Intune oder über die WinCS-APIs möglich.

Was sollte man noch beachten?

Firmware zuerst: ältere Geräte (2015–2020) brauchen oft ein OEM-BIOS-Update.
BitLocker vor dem Update aussetzen – sonst drohen Wiederherstellungsabfragen.
Einbahnstraße: kein Rückbau auf „nur 2011“; alte Boot-Medien neu erstellen.
Keine Werks-Resets von Secure Boot nach der Migration.
Die EFI-Systempartition kann zu knapp bemessen sein.

Wichtiger Hinweis

Secure Boot nicht deaktivieren, um den Ablauf zu umgehen, und das 2011er-Zertifikat nicht entfernen oder sperren.
Beides senkt das Schutzniveau oder macht Geräte startunfähig.

FAQs - Secure-Boot-Zertifikate

Bleiben PCs am 24. Juni 2026 stehen?

Nein. Geräte booten weiter und erhalten weiterhin reguläre Windows-Updates. Ohne Migration entfallen nur die Boot-Level-Schutzupdates.

Muss man Secure Boot deaktivieren?

Nein, keinesfalls. Das senkt das Schutzniveau erheblich. Der richtige Weg ist der Umstieg auf die 2023er-CA.

Werden Server automatisch aktualisiert?

Nein. Windows Server benötigt manuelles Handeln über Registry oder Gruppenrichtlinie.

Woran erkennt man den erfolgreichen Abschluss der Secure Boot-Aktualisierung?

Am Wert UEFICA2023Status = „Updated“ sowie an Event ID 1808 im System-Ereignisprotokoll.

Handlungsempfehlung für IT-Admins

Sinnvoll ist ein gestaffeltes Vorgehen vor dem Stichtag: zunächst eine Inventur des Zertifikatsstands, dann aktuelle Firmware, anschließend ein Pilot-Rollout an validierten Geräten, der wellenweise ausgebaut wird – und durchgehend ein Monitoring über Registry-Status, Event-IDs und Autopatch-Berichte. Den größten Aufwand verursachen Server, Spezialhardware und ältere Images, weil sie nicht vom automatischen Rollout profitieren.

Fazit

Der Stichtag 24. Juni 2026 für die Secure-Boot-Zertifikate ist weniger ein Notfall als eine Frist, die sich mit der gebotenen Sorgfalt gut beherrschen lässt – vorausgesetzt, die Migration wird strukturiert und früh genug angegangen.

Weitere interessante Beiträge

IT-News

Kritische Windows-Server-Lücke im Netlogon-Code: CVE-2026-41089

1. Juni 2026

Zum Blogbeitrag

mars-News

Rückblick auf das 2. Managed NMS Symposium 2026

19. Juni 2026

Zum Blogbeitrag

IT-News

Password Spraying: Wenn Microsoft 365 zur Zielscheibe wird

1. Juli 2026

Zum Blogbeitrag

Fanden Sie den Blogbeitrag hilfreich und interessant?

Vielen Dank für Ihre Rückmeldung!

Der Beitrag Secure Boot-Zertifikate 2026: Stichtag 24. Juni für Windows-Systeme erschien zuerst auf mars solutions GmbH.

Rückblick auf das 2. Managed NMS Symposium 2026

Melissa Reiff — Fri, 19 Jun 2026 09:37:03 +0000

Rückblick auf das 2. Managed NMS Symposium 2026

19. Juni 2026
11:37
Melissa Reiff

Am 18. Juni 2026 durften wir Teil des 2. Managed IT Service Symposiums im Van der Valk Hotel Düsseldorf Airport sein – mittendrin im Austausch mit der Managed-Service-Community.

Nach der erfolgreichen Premiere im vergangenen Jahr, bei der wir ebenfalls als Aussteller vertreten waren, war die Vorfreude auf die zweite Ausgabe groß. Umso schöner war es, auch 2026 wieder dabei zu sein und gemeinsam mit vielen Managed-Service-Profis über die Zukunft von Cloud- und Managed-Service-Geschäftsmodellen zu sprechen.

Ein Tag voller Austausch, Impulse und neuer Perspektiven

Schon beim informellen Get-Together am Vorabend wurde deutlich: Dieses Event lebt vom persönlichen Austausch. In entspannter Atmosphäre konnten erste Gespräche geführt, Kontakte vertieft und neue Verbindungen geknüpft werden.

Am Veranstaltungstag selbst erwartete die Besucher ein vielseitiges Programm mit spannenden Fachvorträgen, strategischen Einblicken und wertvollen Impulsen von Ausstellern und Branchenprofis. Im Mittelpunkt stand dabei vor allem eine Frage:

Wie können IT-Unternehmen den Wandel vom klassischen Dienstleister zum Managed Service Provider erfolgreich gestalten?

Genau hier setzte auch das Nordanex Managed IT Service Programm (NMS) an, das IT-Unternehmen bei dieser Transformation unterstützt und praxisnahe Ansätze für moderne Managed-Service-Modelle bietet.

Wir mittendrin

Für uns war es besonders wertvoll, nicht nur zuzuhören, sondern aktiv Teil des Symposiums zu sein. Als Aussteller konnten wir direkt mit Besuchern, Partnern und anderen Unternehmen ins Gespräch kommen, unsere Perspektiven einbringen und zeigen, welche Rolle lösungsorientierte IT-Services heute spielen.

Die Gespräche an unserem Stand haben einmal mehr gezeigt, wie relevant Themen wie Cloud, Managed Services, Prozessoptimierung und strategische IT-Betreuung für viele Unternehmen geworden sind.

Besonders beeindruckt hat uns:

der offene Austausch mit Besuchern, Partnern und Ausstellern
die hohe Praxisnähe der Fachvorträge
die vielen Gespräche rund um moderne Managed-Service-Geschäftsmodelle
das starke Netzwerk innerhalb der Nordanex-Community
die gemeinsame Motivation, IT nicht nur technisch, sondern strategisch weiterzudenken

Warum solche Events wichtig sind

Die Anforderungen an IT-Unternehmen verändern sich stetig. Kunden erwarten heute mehr als einzelne technische Lösungen. Gefragt sind verlässliche Services, vorausschauende Betreuung und echte Mehrwerte.

Das Symposium hat dafür genau den richtigen Rahmen geschaffen: fachlicher Input, persönliche Gespräche und konkrete Impulse für die Weiterentwicklung als Managed Service Provider.

Fazit

Das 2. Managed IT Service Symposium 2026 war für uns ein voller Erfolg, sowohl als Besucher als auch als Aussteller.

Wir nehmen viele spannende Eindrücke, wertvolle Kontakte und neue Impulse mit. Ein großes Dankeschön geht an das Team von Nordanex für die professionelle Organisation und das starke Programm.

Für uns steht fest: Wer Managed Services ernst nimmt, braucht genau solche Plattformen für Austausch, Orientierung und gemeinsame Weiterentwicklung.

Wir freuen uns schon jetzt auf das nächste Mal.