3 kwietnia 2026 roku badacz ukrywający się za pseudonimem Chaotic Eclipse — na GitHubie znany jako Nightmare-Eclipse — opublikował działający kod eksploita dla podatności w Microsoft Defender. Nadał mu nazwę BlueHammer. Nie zgłosił go wcześniej do programu odpowiedzialnego ujawniania Microsoftu. Opublikował bez ostrzeżenia.
To nie był błąd proceduralny ani niecierpliwość. To był świadomy wybór, który badacz wyjaśnił wprost: próba zgłoszenia przez Microsoft Security Response Center nie doprowadziła do niczego. Według badacza Microsoft "wyczyścił nim podłogę" — zignorowało zgłoszenie, a potem aktywnie go źle traktowało w trakcie procesu ujawniania.
Dwa tygodnie i trzy zero-days później cała historia wygląda jak modelowy przykład tego jak nie powinna wyglądać relacja między niezależnym badaczem a producentem oprogramowania.
BlueHammer: eskalacja uprawnień do SYSTEM
BlueHammer — CVE-2026-33825 — to podatność na eskalację uprawnień lokalnych w platformie oprogramowania antywirusowego Microsoft Defender, którą opisywaliśmy przy okazji Patch Tuesday za kwiecień jako drugi z dwóch zero-dayów tego wydania. Błąd polega na nieprawidłowej walidacji wejścia podczas operacji skanowania złośliwego oprogramowania: atakujący z dostępem do systemu jako zwykły użytkownik może przez wyciągnięcie tego błędu uzyskać uprawnienia SYSTEM — pełną kontrolę nad maszyną.
Ocena CVSS: 7.8. Działający kod eksploita opublikowany 3 kwietnia — jedenaście dni przed Patch Tuesday, bez żadnej łatki.
Microsoft odpowiedział na Patch Tuesday 14 kwietnia: załatał podatność, ale w komunikacie przypisał jej odkrycie dwóm innym badaczom — Zen Doddowi i Yuanpei XU. Chaotic Eclipse w treści posta na GitHubie zwraca na to uwagę z widoczną irytacją.
RedSun: drugi exploit, niezależny wektor, nadal bez łatki
Sześć dni po Patch Tuesday, 15 kwietnia, Chaotic Eclipse opublikował RedSun.
To nie jest wariant BlueHammer. To niezależna podatność w tym samym oprogramowaniu, korzystająca z całkowicie innego mechanizmu. Serce błędu siedzi w obsłudze plików z oznaczeniem chmurowym przez Defender. Gdy oprogramowanie antywirusowe wykrywa plik złośliwy oznaczony jako cloudowy, zamiast go skasować lub poddać kwarantannie — nadpisuje go z powrotem w oryginalnej lokalizacji. To zachowanie samo w sobie jest absurdalne, ale staje się podatnością gdy atakujący może kontrolować cel tego nadpisania.
Przez użycie blokady operacyjnej pliku (oplock) atakujący może przekierować zapis Defendera z oryginalnej lokalizacji złośliwego pliku na dowolny plik systemowy — w tym na pliki w C:\Windows\System32. Efekt: nadpisanie pliku systemowego, po którym wykonanie kodu z uprawnieniami SYSTEM.
Will Dormann, główny analityk podatności w Tharros, niezależnie potwierdził że exploit działa i nadaje uprawnienia SYSTEM na w pełni zaktualizowanym systemie Windows 11.
RedSun nie ma łatki. Na moment pisania tego tekstu Microsoft nie odpowiedział na pytania o harmonogram poprawki.
UnDefend: trzecia broń, inna klasa szkód
Tego samego dnia co RedSun Chaotic Eclipse opublikował UnDefend — trzecią podatność z rzędu.
UnDefend nie eskaluje uprawnień. Robi coś innego: pozwala zwykłemu użytkownikowi bez uprawnień administratora zablokować Defenderowi możliwość pobierania aktualizacji sygnatur lub całkowicie go wyłączyć przy okazji większej aktualizacji platformy.
To brzmi mniej dramatycznie niż pełna eskalacja do SYSTEM — ale ma własną klasę ryzyka. Środowiska które polegają wyłącznie na Defenderze jako linii ochrony i nie mają alternatywnych mechanizmów wykrywania: po skutecznym użyciu UnDefend atakujący może pozbawić system ochrony przed nowymi zagrożeniami. Nie przejmuje maszyny. Oślepia jej obronę.
Huntress potwierdził że wszystkie trzy techniki były aktywnie używane w atakach na prawdziwe cele. BlueHammer i RedSun jako droga do SYSTEM, UnDefend jako neutralizacja mechanizmu ochrony.
"They mopped the floor with me"
Cytat z posta badacza, który Cybernews przytacza bezpośrednio, jest trudny do przetłumaczenia bez utraty intencji: "They mopped the floor with me" — rozbili mnie, wytarli mną podłogę. To nie jest techniczna skarga. To jest opis jak badacz czuje się po próbie współpracy z producentem przez oficjalny kanał.
Chaotic Eclipse twierdzi że złożył zgłoszenie przez Microsoft Security Response Center, próba skończyła się niczym, Microsoft był świadomy że publiczne ujawnienie nastąpi, sprawa była złożona i odrzucona — a mimo to vendor nie podjął żadnych kroków żeby zapobiec sytuacji.
MSRC wydał generyczne oświadczenie o zaangażowaniu w ochronę klientów i koordynowane ujawnianie podatności. Nie odniósł się do konkretnych zarzutów badacza.
Dwa poziomy tej historii
Na pierwszym poziomie to jest historia o trzech podatnościach w Microsoft Defender: jedna załatana, dwie bez łatek, wszystkie trzy aktywnie eksploitowane. Z perspektywy administratora systemu to jest przede wszystkim problem operacyjny wymagający konkretnych kroków.
Na drugim poziomie to jest historia o tym jak działa — a właściwie jak nie działa — model odpowiedzialnego ujawniania podatności w 2026 roku.
Klasyczny model zakłada sekwencję: badacz odkrywa błąd, zgłasza go producentowi, producent naprawia, badacz i producent razem ogłaszają — z uznaniem dla badacza. W tym modelu wszystkie strony wygrywają: producent dostaje czas na łatkę, użytkownicy dostają ochronę, badacz dostaje uznanie i często nagrodę pieniężną.
Model działa gdy producent traktuje badacza poważnie. Kiedy tak się nie dzieje — jak twierdzi Chaotic Eclipse — badacz stoi przed wyborem: przyjąć ignorowanie i nie zrobić nic, albo opublikować i narazić użytkowników na ryzyko w nadziei że presja publiczna zmusi producenta do działania.
Chaotic Eclipse wybrał publikację. Trzy razy z rzędu, w dwóch tygodniach.
Trudno jednoznacznie oceniać tę decyzję. Z jednej strony: kod eksploita w rękach atakujących zanim jest łatka to realne ryzyko dla realnych użytkowników — i tak właśnie skończyło się z wszystkimi trzema. Z drugiej strony: jeśli zgłoszenie przez oficjalny kanał nie przynosi żadnego efektu — jakie inne narzędzia ma badacz żeby zmusić producenta do działania?
To napięcie nie jest nowe. Ale w środowisku gdzie modele AI potrafią znajdować podatności szybciej niż kiedykolwiek, a NIST właśnie przyznał że nie nadąża z przetwarzaniem zgłoszeń — liczba takich sytuacji będzie rosła. Badaczy z niezałatwionymi zgłoszeniami będzie więcej, nie mniej.
Mechanizm RedSun i dlaczego jest nieoczywisty
Warto zatrzymać się przy technicznym sercu RedSun, bo jest elegancki na sposób który pokazuje głębszy problem architektoniczny w Defenderze.
Infrastruktura plików chmurowych w systemie Windows (Cloud Files Infrastructure, cldapi.dll) zarządza plikami synchronizowanymi z usługami chmurowymi jak OneDrive. Pliki oznaczone jako cloudowe mają specjalny atrybut wskazujący że ich zawartość może nie być lokalnie dostępna.
Defender, natrafiając na taki plik podczas skanowania i identyfikując go jako złośliwy, uruchamia procedurę obsługi — która zawiera zapis pliku z powrotem na dysk. Logika za tym zachowaniem jest niejasna nawet dla analityków którzy ją badali. Chaotic Eclipse opisuje ją jako "stupid and hilarious" — ale z perspektywy bezpieczeństwa jest po prostu niebezpieczna.
Blokada operacyjna (oplock) to mechanizm Windows pozwalający procesowi zarezerwować dostęp do pliku przed jego otwarciem przez inny proces. Atakujący używa oplock żeby przechwycić moment gdy Defender próbuje zapisać plik — i w tym momencie podstawia inny cel zapisu. Defender skrupulatnie zapisuje złośliwy plik do C:\Windows\System32, bo tak mu kazano przez przekierowanie.
Co zrobić teraz
BlueHammer (CVE-2026-33825) jest załatany przez Patch Tuesday ze stycznia 2026. Aktualizacja jest wymagana.
RedSun i UnDefend nie mają łatek. Dla RedSun: monitorowanie anomalnej aktywności zapisu Defendera, szczególnie operacji cldapi.dll celujących w C:\Windows\System32, oraz reguły wykrywające zachowania oplock. Dla UnDefend: dodatkowe mechanizmy monitorowania stanu aktualizacji sygnatur Defendera, niezależne od samego Defendera.
Środowiska z wyłączonym Defenderem lub zastąpionym innym oprogramowaniem antywirusowym nie są podatne na RedSun i UnDefend — ale BlueHammer dotyczył samego systemu Windows, nie tylko Defendera jako usługi.
Podsumowanie
Trzy zero-days w Microsoft Defender w dwie tygodnie, opublikowane przez jednego badacza jako forma protestu, wszystkie trzy aktywnie eksploitowane. To jest jednocześnie historia techniczna — o trzech realnych lukach w powszechnie używanym oprogramowaniu ochronnym — i historia systemowa: o tym co się dzieje gdy model odpowiedzialnego ujawniania podatności zawodzi z perspektywy badacza.
Chaotic Eclipse nie jest pierwszym badaczem który stanął przed tym wyborem i nie będzie ostatnim. Ale rzadko zdarza się żeby eskalacja była tak szybka, tak publiczna i miała tak bezpośrednie konsekwencje w postaci aktywnej eksploitacji na prawdziwych celach.
Microsoft nadal nie skomentował zarzutów dotyczących procesu ujawniania. Łatki na RedSun i UnDefend nie zostały jeszcze ogłoszone.
Źródła
BleepingComputer — potwierdzenie działania exploita RedSun przez Dormanna i kontekst całej serii: https://www.bleepingcomputer.com/news/microsoft/new-microsoft-defender-redsun-zero-day-poc-grants-system-privileges/
Help Net Security — opis wszystkich trzech podatności i potwierdzenie aktywnej eksploitacji przez Huntress: https://www.helpnetsecurity.com/2026/04/17/microsoft-defender-zero-days-exploited/
The Hacker News — szczegóły trzech CVE i aktywna eksploitacja: https://thehackernews.com/2026/04/three-microsoft-defender-zero-days.html
SOCRadar — analiza techniczna mechanizmów BlueHammer, RedSun i UnDefend: https://socradar.io/blog/bluehammer-redsun-undefend-windows-defender-0days/
Cybernews — cytat badacza i historia relacji z Microsoft: https://cybernews.com/security/second-public-windows-defender-exploit-released/
