MSXFAQ MeetNow aktiv: Komm doch einfach dazu.

PWN2OWN 2026 - 0-Day Exchange

Diese Seite widmete sich dem vermutlich im Juni oder vorher kommenden Security Update für Exchange SE und vermutlich auch Exchange 2016/2019 um eine kritische Lücke zu fixen, die auf der PWN2OWN 2026 in Berlin von DevCore (Orange Tsai) vorgestellt wurde.

Worum geht es?

Regelmäßig veranstaltet TrendAI (Früher als Trend Micro bekannt) unter dem Begriff "Trend Micro Zero Day Initiative (ZDI)" einen Hackerwettbewerb. "Gute Hacker" können dort ihre gefundenen Lücken in Produkten dem Hersteller und öffentlichkeitswirksam vorstellen. Neben dem Namen und der Firma gibt es auch Preisgelder zu gewinnen. 2026 fand der Event "PWN2OWN Berlin" in Berlin vom 14. Mai bis 16. Mai 2026 statt. Am 15. Mail 2026 wurde eine Lücke in Exchange demonstriert, die laut Aussage der Organisatoren für einige Nachtschichten in Redmond sorgen könnten. "Orange Tsai" von DevCore hat mit KI eine Lücke gefunden die nicht nur Exchange sondern angeblich auch das Windows Server Betriebssystem darunter kompromittiert.

Der Gewinner der diesjährigen Veranstaltung war das DEVCORE-Team: Ein Preisgeld von 505.000 US-Dollar, fast die Hälfte des Gesamtpreises, ging an die Taiwanesen. Sie brachten einen Exploit für die Microsoft-Produkte Sharepoint, Edge und Exchange mit nach Berlin – der Exchange-Exploit erlaubte gar die komplette Übernahme des Servers. Entdecker Orange Tsai sagte im Interview, der Exploitcode sei KI-generiert, basiere aber auf seiner Idee und seinen Anweisungen.
Quelle: https://www.heise.de/news/Millionen-Preisgeld-und-Exchange-Exploit-So-war-die-Pwn2Own-2026-11297824.html

Orange Tsai und seine Firma DevCore sind keine Unbekannten. Er hat schon auf der DEVCON2021 zum Thema ProxyLogon (https://proxylogon.com/) vorgetragen.

 Wrapping Up Pwn2Own Berlin 2026: The Final Numbers
https://youtu.be/SqeskOpUPQU?t=80

Recapping Pwn2Own Berlin Day Two
https://youtu.be/2hFROPRqeCM?t=37

URL Analyse

Die eigentliche Lücke wurde von ZDI kostenfrei an die Hersteller weitergegeben, damit diese eine Lösung erarbeiten können. Das Verfahren ist als "Responsible Disclosure" bekannt, d.h. die Finder oder ein Service melden die Lücke und im Gegenzug wird der Finder bei Bedarf später genannt (Credits), bekommt eine Prämie o.ä.

TrendAI nutzt PWN2OWN 2026 natürlich auch als Publicity und Werbung für ihre Produkte und dazu zählen Pressemitteilungen und natürlich Videos vom Event. Hier wird es dann interessant. Das erste Video ist eigentlich nur eine Zusammenfassung des zweiten Tages und weitere Details sind zu der Lücke noch nicht öffentlich. Aber nicht alle:


Ausschnitt aus https://youtu.be/2hFROPRqeCM?t=43

Es gibt noch zweites Video mit einem leicht anderen Ausschnitt: 


Ausschnitt aus https://youtu.be/SqeskOpUPQU?t=74

Ein weiterer Ausschnitte auf https://youtu.be/SqeskOpUPQU?t=85 zeigt noch mal einen anderen Ausschnitt aber gibt nicht mehr her. Auch YouTube-Shorts liefert oft genauere Bilder, die aber abgeschnitten sind


https://www.youtube.com/shorts/cq0hezWcy_g  

Heise hat auf ihrem Artikel die URL deutlich verschleiert aber lässt die Antwort sichtbar.


Auszug aus: https://www.heise.de/news/Millionen-Preisgeld-und-Exchange-Exploit-So-war-die-Pwn2Own-2026-11297824.html

Bei Heise ist die Bilder-URL interessant, welche am Ende die Breite des Bilds vorgibt

https://heise.cloudimg.io/v7/_www-heise-de_/imgs/18/5/0/8/4/3/6/1/IMG_4886-51f38b23f0f07ff8.jpeg?force_format=avif%2Cwebp%2Cjpeg&org_if_sml=1&q=85&width=610 

Ich habe einfach mal den Parameter "width=12200" gesetzt um das Bild in 20facher breite zu bekommen und es wurde anscheinend nicht hochgerechnet sondern in besserer Auflösung geliefert.


Ausschnitt aus dem großen Bild

Man muss also beim Veröffentlichen von teilverschleierten Bildern darauf aufpassen, dass ein Angreifer nicht aus mehreren Bildern vielleicht das Angriffsmuster ermitteln kann. 

Auch wenn die URL nicht komplett sichtbar ist, kann man schon erahnen, wohin es geht:

  • Hostname
    Die URL zeigt einen FQDN eines Exchange Servers. Er könnte auch von extern erreichbar sein.
  • URL vermutlich OWA
    Auch wen wenn es nicht genau sichtbar ist, bleibt ja nur /owa, /ecp, /ews, /oab von der Zeichenlänge übrig und ich würde auf "/owa" tippen.
  • ASPX-Seite als Starter
    Die URL startet eine ASPS-Datei, die anscheinend mit "l" beginnt und auf "*bj.aspx" endet. Ich habe sowohl Exchange 2019 und SE-Server durchsucht aber keine vergleichbar klingelnde Datei gefunden

    Das muss aber nichts heißen. Theoretisch kann ein Exchange Handler im IIS diese Datei aus dem Code extrahieren und InMemory ausführen.
  • Payload ist VBScript
    Die partiell sichtbare Payload scheint ein "IIS.Response"-Objekt zu starten, welches ein "ActiveXObject" vom Typ "WScript.Shell" startet und als ersten  Befehl einen "cmd /c whoami" ausführt. Die weiteren Befehle kann ich nicht weiter erkennen aber wenn ich eine Shell als "LocalSystem" habe, dann kann ich mir alle andere Befehle selbst ausdenken

Ich vermute, dass auch diese Lücke einen Codenamen wie ProxyLogon und Hafnium bekommt und der Autor eine entsprechende Webseite bereitstellt.

Entsprechende Links reiche ich nach. 

Update

Aktuell (stand 19. Mai 2026) gibt es noch kein Update oder Patch von Microsoft für diese Lücke und auch noch keine Bestätigung oder ein CVE-Eintrag mit weiteren Details. Aber wenn ich über eine anonym erreichbare URL ohne Authentifizierung auf dem Server Befehle mit einem privilegierten Konto starten kann, dann sind wir nahe dran am Hafnium Exploit.

Exchange Administratoren sollten wohl davon ausgehen, dass Exchange SE im Juni oder vorher ein Security Update bekommt und wenn die Lücke auch in Exchange 2016/2019 vorhanden ist, dann wird es interessant, ob diese Lücke auch für Kunden ohne ESU2-Lizenz gepatched wird. Ob Microsoft hier noch mal Updates wie bei Hafnium Exploit bereitstellt?

Gegenmaßnahmen

Ohne detaillierte Informationen über die Lücke kann ich nur spekulieren. Denkbar sind zwei Gegenmaßnahmen, die sie heute schon einsetzen könnten

  • HTTP Payload Filterung
    Der Schadcode wird hier über die Payload an den Server übertragen. Leistungsfähigere WebApplicationFirewalls oder Loadbalancer terminieren die HTTPS-Anfragen vor Exchange, decodieren den Inhalt und senden ihn verschlüsselt an die dahinter liegenden Webserver weiter, wenn der Inhalt unbedenklich ist. Eine einfache Suche nach "cmd.exe", "wscript.shell", "ActiveXObject" in dem einfach URLEncodierten Daten sollte eine direkte Blockierung ermöglichen. Ich kann mir kaum vorstellen
  • PreAuthentifizierung
    Eine zweite Option ist eine vorgeschaltete Authentifizierung. Der Anwender landet wieder auf einem Reverse Proxy, der erst eine Anmeldung des Benutzers, gerne auch mit MFA, erforderlich macht. Erst wenn der Benutzer dann legitimiert ist, wird der Zugriff z.B. per Kerberos - Constraint Delegation an einen Exchange Server weitergegeben. Ein anonymer Zugriff auf den Exchange Server findet dann eigentlich nicht mehr statt. Allerdings sind dann immer noch die Benutzer ein Risiko, deren Zugangsdaten bei Angreifern auf Vorrat auf den Einsatz warten.

Wenn Sie ihren Exchange Server schon auf Hybrid Modern Authentication (HMA) umgestellt haben, dann sind sie vermutlich nicht geschützt, da hier ja ein erster anonymer Zugriff auf Exchange genutzt wird, den Exchange mit einem 401 und Bearer-Header beantwortet. Der Angriff braucht scheinbar aber gar keine Anmeldung.

Als Exchange Admin sollten Sie die nächsten Tage also wachsam bleiben.

Weitere Links