GitHub sperrt Sicherheitsforscher, der einen Zero-Day-Windows-Exploit veröffentlicht hat

• Das GitHub-Konto von Nightmare-Eclipse wurde gesperrt; er verlegte seine Arbeitsumgebung zu GitLab und bezeichnete dies als Vergeltungsmaßnahme von Microsoft
• Der Konflikt eskalierte Anfang April mit der Veröffentlichung des BlueHammer-Zero-Day; Eclipse erklärte, Microsoft habe Meldungen und Forderungen nach einer Belohnung ignoriert
• Microsoft legte weder Grund noch Ablauf der Sperre offen, sodass unklar bleibt, ob es um eine nicht standardmäßige Offenlegung oder um ein Scheitern bei Melde- und Belohnungsprozessen geht
• Eclipse veröffentlichte sechs Windows-Zero-Days, darunter BlueHammer, RedSun und UnDefend; einige davon werden in realen Umgebungen aktiv ausgenutzt
• Die GitHub-Sperre kann bereits veröffentlichten Code und dessen Missbrauch kaum stoppen und zeigt angesichts der durch KI beschleunigten Schwachstellenforschung die Grenzen bestehender Offenlegungs- und Patch-Prozesse auf

---

Sperrung des GitHub-Kontos und Wechsel zu GitLab

• Microsoft sperrte das GitHub-Konto des Sicherheitsforschers Nightmare-Eclipse (Chaotic Eclipse) aus bislang nicht öffentlich genannten Gründen
• Eclipse verlegte seine Arbeitsumgebung zu GitLab und erklärte, auch das für Bug-Meldungen genutzte Microsoft-Konto sei bereits gelöscht worden
• In einem Blogbeitrag behauptet er, die Maßnahme sei vergeltend, Microsoft habe die Kommunikation verweigert und keine Belohnung gezahlt
• Microsofts MSRC-Bounty-Programm zahlt je nach Bedingungen für Endpoint-Zero-Days bis zu 30.000 bis 100.000 US-Dollar und für Hyper-V-Schwachstellen bis zu 250.000 US-Dollar
• Eclipse hat bereits sechs Zero-Day-Exploits veröffentlicht und deutete an, dass es am 14. Juli weitere Veröffentlichungen zu Microsoft geben könnte

Der Konflikt zwischen Microsoft und Eclipse

• Der Konflikt verschärfte sich Anfang April, als Eclipse den BlueHammer-Zero-Day ohne Vorwarnung veröffentlichte
• Eclipses Blog kritisiert Microsoft und das MSRC scharf und behauptet, Microsoft habe Zero-Day-Meldungen ignoriert oder abgelehnt und zudem die geforderte Belohnung nicht ausgezahlt, was zu finanziellem Schaden geführt habe
• Eclipse behauptet, von Microsoft die Aussage gehört zu haben, man werde ihm „das Leben ruinieren“, und erklärt, genau das sei geschehen; zudem gebe es eine Art Deadman-Switch
• Da Microsoft keine Details zum Ablauf veröffentlicht, ist schwer zu beurteilen, ob es sich um einen Forscher handelt, der standardisierte Offenlegungsverfahren nicht eingehalten hat, oder um ein Unternehmen, das Sicherheitsmeldungen unnötig erschwert

Kontroverse um MSRC-Verfahren und Druck auf Offenlegungsrichtlinien

• William Dormann von Tharros kritisierte in einem Beitrag zu BlueHammer, das MSRC sei früher kooperativ gewesen, habe aber aus Kostengründen erfahrene Fachleute entlassen und nur noch Personen belassen, die strikt nach Ablaufplänen arbeiten
• Dormann meint, dass das MSRC inzwischen offenbar die Einreichung von Exploit-Videos verlange; es sei möglich, dass Microsoft den Fall geschlossen habe, weil der Melder kein Video eingereicht habe
• Da Microsoft schweigt, bleibt unklar, ob die tatsächliche Praxis bei verantwortungsvoller Offenlegung von Schwachstellen und in Bounty-Programmen der Kern dieses Konflikts ist
• Im Zuge KI-gestützter Sicherheitsforschung heißt es, die standardmäßige 90-Tage-Frist für Offenlegung und Patch sei faktisch zu einem veralteten Modell geworden
• Vor dem Hintergrund, dass die Zeit bis zum Exploit und ungenutzte Exploits beide gegen null tendieren, wächst der Druck auf Microsoft und andere Softwareanbieter, ihre Richtlinien anzupassen

Veröffentlichte Windows-Zero-Days

• Eclipse veröffentlichte mehrere Windows-Zero-Day-Exploits
• BlueHammer ist eine Schwachstelle, mit der sich über Defender SYSTEM-Rechte erlangen lassen
• RedSun ermöglicht ebenfalls Zugriff mit SYSTEM-Benutzerrechten
• UnDefend kann Defender offline setzen
• GreenPlasma verschafft über den CTFMon-Dienst SYSTEM-Zugriff
• MiniPlasma ermöglicht über einen Fehler im Windows-Cloud-Filter-Treiber eine ähnliche Rechteausweitung
• YellowKey ist eine BitLocker-Schwachstelle, durch die Angreifer mit minimalem Aufwand verschlüsselte Laufwerke öffnen können, womit der zentrale Zweck von BitLocker unterlaufen wird

Tatsächliche Ausnutzung und sicherheitspolitische Folgen

• BlueHammer, RedSun und UnDefend werden nachweislich in realen Umgebungen aktiv ausgenutzt
• Für die übrigen Schwachstellen wurde vollständiger oder teilweiser Proof-of-Concept-Code veröffentlicht, wodurch sie für interessierte Angreifer leicht nutzbar werden
• Die Sperrung des GitHub-Kontos reicht nicht aus, um bereits veröffentlichten Code zu entfernen oder Missbrauch zu verhindern, und verschärft den Konflikt zwischen Forschern und Plattformbetreibern weiter
• Das Zusammenspiel aus Zero-Day-Veröffentlichungen, Streit um Bounty-Zahlungen, Kontosperrungen und durch KI beschleunigter Schwachstellenforschung macht die Grenzen der bisherigen Prozesse für Meldung, Prüfung und Patching von Sicherheitslücken noch deutlicher

[GN⁺]

Hacker-News-Kommentare

• Wenn ich in einer Web-App einen Sicherheitsfehler finde, melde ich ihn nicht mehr. Beim ersten Mal wäre ich fast von der Polizei verhaftet worden, und beim zweiten Mal hat man mir nicht einmal geantwortet, sondern direkt meinen Arbeitgeber kontaktiert und gesagt, meine Meldung sei unangenehm gewesen und ich hätte nach der Behebung darüber schreiben wollen
  Danach kam ich zu dem Schluss, dass sich dieser Aufwand nicht lohnt, und wenn ich es einfach lasse, habe ich selbst einen ruhigen Tag

  • Wenn man will, kann man Schwachstellen an das Finnish Cyber Security Centre melden, und dort übernimmt man die Meldung und Vermittlung mit den betroffenen Parteien
    Das geht auch völlig anonym, sodass man sich keine Sorgen machen muss, dass ein überempfindliches Unternehmen einem das Leben ruiniert. Das FCSC von Traficom ist ein großer Gewinn dafür, dass White-Hat-Sicherheitsforscher weiterhin zum Gemeinwohl beitragen können
  • Einmal postete eine Bahnlinie in sozialen Medien ein Foto nach dem Motto „jemandem etwas Gutes getan“, und an der Wand im Büro auf dem Bild hing ein A4-Blatt mit Benutzernamen und Login-Informationen für mehrere Systeme
    Ich meldete es an drei auffindbare Kontaktstellen, aber nur eine antwortete und fragte, was diese Systeme machten und worin das Risiko bestehe. Ich wusste das überhaupt nicht und hatte ganz sicher nicht vor, mich in unbekannte Systeme einzuloggen, um das herauszufinden, also antwortete ich, man solle es an die interne IT weitergeben und prüfen lassen, dass die Daten geändert oder ersetzt werden
    Am Ende bekam ich die Antwort, man danke mir für meine Sorgfalt und habe das Foto gelöscht, also sei das Problem gelöst. Ich hoffe, dass es jemand mit Verständnis tatsächlich geprüft hat, aber ich habe beschlossen, mich nicht weiter einzumischen
  • Es ist besser, sich nicht darum zu kümmern
    Ich habe eine Zeit lang beruflich als White Hat gearbeitet, aber ich stimme zu, dass ehrliche und hilfreiche Absichten heute riskant sind. Selbst wenn jemand beschließt, Schwachstellen zu verkaufen, würde ich das einfach so hinnehmen
  • Manche kritisieren zwar Regulierung, aber der von der EU vorgeschriebene Cyber Resilience Act (CRA) hat Unternehmen dazu gebracht, eine klare Kontaktstelle für Schwachstellenmeldungen bereitzustellen und tatsächlich darauf zu reagieren
  • Man könnte auch versuchen, den Exploit anonym bei einer Regierungsbehörde zu melden

• Ich weiß nicht, was hier genau vor sich geht, aber die erste Regel großer Bug-Bounty-Programme ist, dass alle Beteiligten auf Seiten des Vendors starke Anreize haben, Auszahlungen zu veranlassen
  In vielen Fällen gibt es intern Kennzahlen, an denen Personen hängen, und in solchen Programmen ist eine Auszahlung etwas, das man feiert. Es ist daher fast sicher schwer zu behaupten, Microsoft würde Bounty-Fordernde schikanieren, um Geld zu sparen
  Für kleine Firmen mag das nicht gelten, und das ist auch ein Grund, warum kleine Firmen keine Bug Bounties betreiben sollten, aber für Unternehmen in FAANG-/MAG7-Größe gilt das eindeutig. Das heißt nicht, dass solche Programme bei Auszahlungen immer großzügig sind oder nie Entscheidungen treffen, die Leute verärgern. Es passt nur nicht zu der Behauptung, man halte Zahlungen aus Groll zurück
  Allerdings ist es schon eine Weile her, dass ich mit Leuten von Microsoft darüber gesprochen habe, daher mit etwas Vorbehalt

  • Wenn man den Beitrag von YellowKey liest, sieht es so aus, als sei in zumindest einigen Fällen eine offizielle Backdoor von Microsoft offengelegt worden, wie sie US-Geheimdienste und andere nutzen. Die Aussage ist, dass BitLocker nicht sicher ist und eine Backdoor hat
    Nach allem, was damals mit TrueCrypt passiert ist — als es plötzlich eingestellt, alle Downloads entfernt und allen empfohlen wurde, zu Microsoft BitLocker zu wechseln — war das nichts völlig Unerwartetes
    [1] - https://www.tomshardware.com/tech-industry/cyber-security/mi...
  • Angefangen hat das damit, dass die Bürokratie sich weigerte, Bluehammer überhaupt zu prüfen, nachdem es nicht gelungen war, den Melder dazu zu bewegen, ein Video vorzulegen
    Und dann statt die Bürokratie zu reparieren noch weiterzugehen und das Konto zu sperren, ist wirklich kein gutes Bild. Ich verstehe nicht, warum man Microsoft dabei guten Willen unterstellen sollte
  • Der von dieser Person gemeldete Bug wirkt wie eine sehr offensichtliche BitLocker-Backdoor und wirft sehr ernste Fragen darüber auf, was Microsoft bei Verschlüsselung eigentlich tut
    Es scheint gut möglich, dass sich Volumes auch ohne den Benutzerschlüssel entschlüsseln lassen, und das ist extrem besorgniserregend. Es wirkt, als wolle man so tun, als wäre nichts gewesen, aber es ist bereits öffentlich geworden
  • Wenn sie nach der Sperre klug gewesen wären, hätten sie ihn für viel Geld eingestellt. Solche Großunternehmen sind zwar angespannt, aber wenn sie nicht dumm sind, zahlen sie Geld
    Da es um Microsoft geht, ist das vielleicht nicht das fortschrittlichste Unternehmen in solchen Fragen, daher weiß ich nicht, ob ihnen das klar geworden ist
  • Als ich in der Prüfung von Bug Bounties gearbeitet habe, habe ich nie Belege dafür gesehen, dass man Auszahlungen vermeiden wollte. Das Schlimmste, was ich auf Unternehmensseite erlebt habe, war, dass in einem Proof of Concept um „bitte kein X“ gebeten wurde und ein Forscher, der diese Anweisung ignorierte, am Ende sogar mehr Geld bekam
    Der Grund war schlicht, dass das nachgewiesene Risiko größer war. Umgekehrt gab es bei einem großen Programm einen Forscher, der vor langer Zeit überzeugend dargelegt hatte, dass sich mit einem gewöhnlichen XSS-Exploit ein Effekt erzielen lässt, der einer höheren Auszahlungsklasse entspricht; danach bekam er bei jedem gefundenen XSS weiterhin unangemessen hohe Einstufungen, weil er denselben Proof of Concept beilegte. Die XSS anderer Forscher wurden nach der in der Tabelle vorgesehenen XSS-Klasse vergütet
    Tatsächlich fällt mir ein echter Ausnahmefall ein. Jemand hatte den heiligen Gral geschafft und eine Webshell auf den Servern des Unternehmens installiert, was nach heutigen Maßstäben mehr als 10.000 Dollar wert gewesen wäre. Aber die Person ließ die Webshell bestehen und reichte nur den Bericht ein. Der Programmverantwortliche war außer sich und sagte ausdrücklich, allein deshalb wolle er keine Bounty auszahlen. Ob am Ende gezahlt wurde, weiß ich nicht mehr

• Ich glaube, Microsoft wird das noch bereuen
  Jemand findet einen Zero-Day, bekommt aber keine Belohnung und stattdessen nur ein gesperrtes Konto. Dann verkauft diese Person den Zero-Day eben anderswo

  • Aber in dieser Geschichte geht es doch darum, dass der Zero-Day-Exploit nicht verkauft, sondern veröffentlicht wurde. So steht es auch in der Überschrift
    Und es gab auch eine Sperre bei GitLab, das mit Microsoft nichts zu tun hat
  • Es gibt auch andere Leute, die nach Zero-Days suchen. Ruf ist sehr wichtig
  • Es dürfte auch kein Problem sein, einen Zero-Day anderswo zu verkaufen. Die CIA kann offenbar auf Wunsch eines ranghohen Beamten Goldbarren im Wert von mehreren Millionen Dollar bereitstellen, also braucht man für den Kauf eines Exploits vermutlich nicht einmal eine Bestellung

• In den letzten Monaten habe ich bei mehreren verwandten Vorfällen viele seltsame digitale Reaktionen erlebt, und es war frustrierend, nicht genau benennen zu können, was falsch läuft. Dann las ich in dem Artikel diesen Satz
  „Aber um Kosten zu sparen, hat Microsoft die erfahrenen Leute entlassen und nur noch Flowchart-Befolger übrig gelassen.“
  Der Ausdruck Flowchart-Befolger ist merkenswert. Das sind Leute, die nicht dafür bezahlt werden, zu denken, sondern dafür, vorgegebene Abläufe zu befolgen. In naher Zukunft werden wir solchen Flowchart-Befolgern wohl viel häufiger begegnen, ob digital oder als reale Menschen

  • Die meisten Unternehmens-Sicherheitsberatungen, mit denen ich früher zu tun hatte, arbeiteten nach Checklisten
  • In vielen Blue-Collar-Berufen wie Mechanikern, Elektrikern oder Bauunternehmern ist das Befolgen eines flowchart faktisch Gesetz, und Verfahren sind mit Blut und Haftung geschrieben
    Dagegen sehen sich IT-Leute, Ops und Entwickler als handwerklich geprägte, frei denkende Wissensarbeiter. Sie verbinden Können eher mit Abkürzungen, Hacks und Denken außerhalb der Vorgaben als mit dem Befolgen von Verfahren

• Gibt es irgendeine öffentliche Stellungnahme dazu, was bei Microsoft passiert? Warum haben Microsoft und GitLab diesen Nutzer beide gesperrt?
  Ich dachte, beide Plattformen erlauben das Hosting von Exploits und Sicherheitsforschung, solange es von Anfang an klar gekennzeichnet ist; offenbar wurde aber irgendeine Regel verletzt

  • Wenn es sich um einen Full-Disk-Encryption-Exploit handelt, der weiterhin physischen Zugriff auf die Hardware erfordert, wurde er vielleicht für eine dreibuchstabige Regierungsbehörde oder etwas in der Art entwickelt

• Wird schon gutgehen, wenn man den Boten erschießt

  • Vielleicht will man die Leute lieber dazu bringen, an staatliche Stellen zu verkaufen, statt Schwachstellen zu patchen

• Hat Microsoft sich selbst eine redaktionelle Verantwortung geschaffen, Zero-Days von GitHub zu entfernen?
  Wenn ein Zero-Day in meiner Software auf GitHub erscheint, wird Microsoft dann auch dieses Konto sperren?

  • Ich verstehe nicht, warum diese Maßnahme bedeuten sollte, dass man künftig auch gegen andere Konten vorgehen müsste

• Diese Situation zeigt sehr gut den strukturellen Interessenkonflikt, der daraus entsteht, dass Microsoft GitHub besitzt
  GitHub hat klare Nutzungsbedingungen zum Hosting aktiv weaponisierter Exploits, aber wenn Forscher gesperrt werden, die auf Windows zielen, wirkt das selbst bei berechtigtem Grund zwangsläufig wie Vergeltung

• Sehr wichtige Information:
  https://www.theregister.com/security/2026/05/28/microsoft-0-...
  In dem verlinkten Microsoft-Blogpost heißt es:
  „Die Details dieser Schwachstellen wurden Microsoft vor der Veröffentlichung nicht mitgeteilt, und ihre Veröffentlichung setzte Kunden unnötigen Risiken aus.“
  Lügt Microsoft also? Wenn nicht, warum hat Nightmare-Eclipse es nicht gemeldet? Das ist eine ziemlich merkwürdige Situation

  • Mich stört die Formulierung „ihre Veröffentlichung setzte Kunden unnötigen Risiken aus“
    Ob verantwortungsvolle Offenlegung oder nicht: Es war nicht der Forscher, der Kunden in Gefahr gebracht hat, sondern Microsoft selbst
  • Ein Grund dafür, dass Nightmare-Eclipse es nicht gemeldet hat, könnte sein, dass es sich um eine Tarnorganisation eines ausländischen Geheimdienstes handelt, die sich als unzufriedener Forscher ausgibt
  • Mit Kunden sind hier vielleicht nicht Leute oder Unternehmen gemeint, die für eine Lizenz bezahlt haben, sondern die Akteure, die diese Backdoor angefordert haben