Брешь в защите: Война Nightmare Eclipse. Часть 2

Хабр, привет!

На связи Александр Бек, аналитик-исследователь угроз кибербезопасности R‑Vision. В первой части мы разобрали три PoC от Nightmare Eclipse — YellowKey, GreenPlasma и MiniPlasma. Это были совершенно разные техники: обход BitLocker через WinRE, низкоуровневый примитив на стыке CTF и Windows Object Managerи цепочка локального повышения привилегий (LPE), основанная на взаимодействии Cloud Files с Windows Error Reporting.

Тогда стало понятно, что защищаться от этих техник приходится по-разному. В одних случаях телеметрии практически нет, в других — можно строить вполне рабочие детекты по реестру, процессам и файловой системе.

В этой статье мы разберем оставшиеся пять PoC. Среди них — четыре уязвимости в Microsoft Defender (три LPE и одна DoS), а также еще один вариант обхода BitLocker через WinRE. Что особенно важно, три из этих техник уже были замечены в реальных атаках. Также мы сосредоточимся не только на механике эксплуатации, но и на том, какие артефакты оставляют эксплойты в системе, какие изменения происходят на устройствах Windows и на что стоит обратить внимание SOC- и threat hunting-командам при поиске следов компрометации.

Что произошло и почему это важно

Коротко напомним хронику.

Nightmare Eclipse (ранее известный как Chaotic Eclipse) — независимый исследователь, который с апреля по июнь 2026 года выкладывал PoC для Windows, минуя все стандартные процедуры согласованного раскрытия. У него явный конфликт с Microsoft, и в итоге технические детали с рабочими эксплойтами оказывались в открытом доступе до официальных патчей или до того, как защитники успевали подготовить нормальные детекты. Сам исследователь пояснил, что он действует так же нечестно, как и Microsoft Security Response Center (MSRC) поступает с отчетами по уязвимостям от независимых «белых хакеров». Кстати, даты пополнения репозиториев тоже выглядят по-особенному: некоторые источники говорят, что Nightmare Eclipse намеренно публикует PoC сразу после Patch Tuesday, подчёркивая конфликт с вендором.

Сегодня разбираем оставшиеся пять PoC: BlueHammer, RedSun, UnDefend, RoguePlanet и GreatXML. Они сильно отличаются и по векторам, и по возможностям обнаружения. Где-то мы снова увидим знакомые приёмы (VSS, oplock, Cloud Files), а где-то столкнёмся с новыми техниками — вроде RPC-интерфейса Defender или «ослепления» антивируса через блокировку файлов.

И вот что важно: BlueHammer, RedSun и UnDefend уже наблюдались в реальных атаках или попытках эксплуатации. Исследователи Huntress рассказали о случае использования BlueHammer в целевых вторжениях, а RedSun и Undefend встречались в пост-эксплуатационных сценариях, что также было подсвечено на портале CISA KEV (BlueHammer, RedSun, UnDefend).

Общая таблица по эксплоитам

Как и в прошлой статье, начнём с краткой сводки для тех, кому нужно сразу понять суть.

Полные идентификаторы CVE и особенности детектирования рассмотрим далее при разборе каждого PoC.

Четыре уязвимости в Microsoft Defender совсем не похожи на «экзотику» на уровне YellowKey, а скорее выглядят как прямое оружие для захвата системы. Три из них (BlueHammer, RedSun и RoguePlanet) дают полноценный SYSTEM shell, а UnDefend позволяет ослепить защиту. GreatXML тоже несет серьёзную угрозу, особенно в условиях физического доступа.

В рамках этой статьи мы разберем механику работы каждого публичного эксплоита и постараемся выявить артефакты, которые можно получить при помощи сбора событий Windows и какие из них сгодятся для детектирования.

BlueHammer

BlueHammer (CVE‑2026‑33825) — LPE-уязвимость в Microsoft Defender, основанная на TOCTOU race condition в механизме обновления сигнатур. Используя RPC и объектные символические ссылки атакующий заставляет Defender записать подконтрольный файл в системную папку или открыть доступ к SAM, получая привилегии SYSTEM.

Механика работы BlueHammer

1. Проверка и загрузка обновлений Defender

Сразу после запуска эксплойт через Windows Update API проверяет наличие обновлений сигнатур, скачивает CAB-файл с официального сервера и извлекает легитимные файлы сигнатур.

2. Создание теневой копии (VSS) для доступа к SAM

Во временной директории создаётся EICAR-файл, чтобы инициировать сканирование Defender. Затем устанавливается batch oplock на библиотеку RstrtMgr.dll. Когда Defender открывает этот DLL во время сканирования, его работа блокируется. Отдельный поток отслеживает появление новых объектов HarddiskVolumeShadowCopy. Как только Defender заморожен, система создаёт VSS, и путь перехватывается.

3. RPC-вызов к Defender с подменой пути

Эксплойт подключается к RPC-конечной точке Defender и вызывает процедуру ServerMpUpdateEngineSignature, передавая в качестве пути заранее подготовленную объектную символическую ссылку:

\Sessions\<SessionId>\BaseNamedObjects\<GUID>\WDUpdateDirectory

4. Гонка и перенаправление на VSS

Defender начинает обновление: создаёт новую папку в C:\ProgramData\Microsoft\Windows Defender\Definition Updates\ и копирует туда файлы. Эксплойт отслеживает создание директории. Как только папка появляется, он устанавливает batch oplock на файл обновления в своей папке и ждёт, пока Defender попытается его прочитать. В момент блокировки он переназначает объектную ссылку на путь:

\Device\HarddiskVolumeShadowCopyX\Windows\System32\Config\SAM

после чего открывает файл SAM через CreateFileTransacted.

5. Извлечение и подмена паролей

Используя offline registry API (offreg.h), эксплойт читает структуры учётных записей и расшифровывает NTLM-хеши, используя данные SYSTEM/LSA для расшифровки SAM. Для каждого пользователя (кроме текущего и WDAGUtilityAccount) он меняет пароль на заранее известный через SamiChangePasswordUser. Если пользователь входит в группу администраторов, создаётся служба со случайным GUID-именем, которая запускает поддельный процесс с привилегиями SYSTEM. После завершения работы исходный хеш восстанавливается.

Ключевые артефакты BlueHammer

Если подозреваете эксплуатацию, в первую очередь смотрите на события доступа к SAM через VSS и на создание директорий в папке Defender Definition Updates не от процессов самого Защитника.

RedSun

RedSun (CVE‑2026‑41091) — LPE-уязвимость в Microsoft Malware Protection Engine. Она эксплуатирует некорректную обработку облачных файлов (Cloud Files placeholders) в связке с directory junctions от имени Defender. Атакующий создаёт cloud-файл с вредоносным содержимым, заставляет Defender его просканировать, а затем через junction (точку соединения) перенаправляет запись на системный файлC:\Windows\System32\TieringEngineService.exe. В результате Defender в контексте SYSTEM создаёт условия для перезаписи этого файла, после чего эксплойт самостоятельно копирует свой исполняемый файл в System32, а служба Storage Tiers Management запускает его с правами SYSTEM.

Механика работы RedSun

1. Подготовка рабочего каталога и EICAR-файла

Эксплойт создаёт уникальный каталог в %TEMP% (например, %TEMP%\RS-{GUID}) и помещает в него файл TieringEngineService.exe, содержащий EICAR-строку. Затем файл открывается для чтения, что инициирует сканирование Microsoft Defender.

2. Создание Shadow Copy и захват oplock

Запускается поток, который отслеживает появление новых объектов HarddiskVolumeShadowCopy в \Device. Как только Defender начинает обрабатывать EICAR-файл, система создаёт теневую копию тома (VSS). Поток перехватывает путь к VSS, открывает в ней тот же TieringEngineService.exe и устанавливает batch oplock. Работа Defender блокируется.

3. Создание облачного placeholder-файла

Эксплойт регистрирует рабочий каталог как sync root с помощью CfRegisterSyncRoot под именем провайдера SERIOUSLYMSFT. Затем создаётся placeholder-файл TieringEngineService.exe через CfCreatePlaceholders. Defender воспринимает его как облачную заглушку, после чего оригинальный EICAR-файл удаляется.

4. Переименование каталога и создание directory junction

Эксплойт переименовывает рабочий каталог во временное имя (с суффиксом .TMP), после чего создаёт новый каталог с исходным именем. В нём создаётся пустой файл TieringEngineService.exe с атрибутом FILE_ATTRIBUTE_READONLY, на который устанавливается oplock. Затем файл переименовывается и удаляется, а на каталог устанавливается directory junction, указывающий на:

C:\Windows\System32

5. Гонка и перезапись системного файла

Эксплойт в цикле пытается открыть C:\Windows\System32\TieringEngineService.exe на запись через NtCreateFile. Defender обращается к пути, который благодаря directory junction перенаправляется в System32. PoC добивается получения дескриптора с правом записи и копирует payload.

В результате обращение к

%TEMP%\RS-{GUID}\TieringEngineService.exe

незаметно перенаправляется на

C:\Windows\System32\TieringEngineService.exe

Работая с привилегиями SYSTEM, Defender перезаписывает системный файл подконтрольным содержимым, после чего эксплойт копирует свой исполняемый файл в C:\Windows\System32\TieringEngineService.exe, закрепляя полезную нагрузку.

6. Запуск подменённой службы

Эксплойт вызывает функцию LaunchTierManagementEng(), которая создаёт COM-объект с CLSID {50d185b9-fff3-4656-92c7-e4018da4361d}. Это приводит к запуску службы TieringEngineService.exe с привилегиями SYSTEM.

7. Запуск консоли от имени SYSTEM

Через именованный канал REDSUN (название может отличаться в зависимости от форка PoC) эксплойт получает идентификатор сессии интерактивного пользователя и запускает conhost.exe с привилегиями SYSTEM в этой сессии.

Ключевые артефакты RedSun

Ниже приведён пример корреляционного фильтра на VRL, который выявляет создание файла TieringEngineService.exe во временной директории — одного из характерных артефактов работы RedSun.

.device_vendor == "microsoft" &&.device_product == "windows" &&.device_event_id == "11" &&dst_file_name == "TieringEngineService.exe" &&contains(dst_file_path, "\\Temp\\")

Корреляционный фильтр, построенный выше, ожидает одно из самых первых событий, вызванных RedSun, а также поскольку это лишь подготовка почвы для эксплуатации, поймать вовремя работу PoC получится вне зависимости от исхода его выполнения. Даже если, например, из-за новой версии Defender эксплуатация не удастся, мы все равно узнаем, что была ее попытка.

UnDefend

UnDefend (CVE‑2026‑45498)— DoS-уязвимость в Microsoft Defender Antimalware Platform, связанная с отсутствием защиты критически важных файлов от монопольной блокировки.Эксплойт позволяет нарушить работу Defender, блокируя доступ к его служебным файлам, и поддерживает два режима работы:

• Passive (блокировка обновлений): блокирует файлы в папке Backup и новые файлы обновлений при их появлении — Defender не может завершить обновление сигнатур.

• Aggressive (отключение защиты): при остановке службы WinDefend (например, при крупном платформенном обновлении) блокирует основной движок mpavbase.vdm, из-за чего Defender не может перезапуститься и остаётся выключенным.

Механика работы UnDefend:

1. Блокировка файлов резервного копирования

Эксплойт открывает файлы mpavbase.lkg и mpavbase.vdm в каталоге

%ProgramData%\Microsoft\Windows Defender\Definition Updates\Backup\

и устанавливает на них монопольную блокировку через LockFileEx. В результате резервные копии становятся недоступны и не могут использоваться при сбое обновления.

2. Регистрация callback на остановку службы WinDefend (агрессивный режим)

Эксплойт вызывает NotifyServiceStatusChangeW с событием SERVICE_NOTIFY_STOPPED для службы WinDefend, чтобы отслеживать её остановку.

3. Мониторинг каталога Definition Updates (пассивный режим)

С помощью ReadDirectoryChangesW эксплойт отслеживает каталог Definition Updates. При появлении новых файлов они сразу открываются с монопольной блокировкой, из-за чего Defender не может читать или записывать их.

4. Блокировка engine-файла при остановке Defender (агрессивный режим)

Когда служба WinDefend останавливается (например, во время обновления платформы), срабатывает зарегистрированный callback. Эксплойт открывает файл mpavbase.vdm с монопольной блокировкой. В результате Defender не может завершить перезапуск и остаётся отключённым до перезагрузки системы или снятия блокировки.

5. Дополнительная блокировка MRT

Отдельный поток отслеживает каталог

C:\Windows\System32\MRT

и блокирует любые изменяемые файлы, препятствуя обновлению Microsoft Malicious Software Removal Tool (MRT).

Результат:

• Пассивный режим: Defender с устаревшими сигнатурами, не обновляется, не видит новые угрозы.

• Агрессивный режим: может оставить Defender в состоянии engine unavailable до перезагрузки/снятия блокировки/успешного обновления.

Ключевые артефакты UnDefend:

UnDefend — тихий DoS-эксплойт, он не повышает привилегии, но создаёт опасное окно для последующих атак. Чтобы его обнаружить, имеет смысл отслеживать подозрительное открытие mpavbase.lkg и mpavbase.vdm, а также изменения в Definition Updates не от процессов АВПО.

GreatXML

GreatXML — второй после YellowKey обход BitLocker через Windows Recovery Environment (WinRE). Для этой техники на момент публикации CVE не присвоен. Атакующий копирует специально подготовленный unattend.xml в корень recovery-раздела. При загрузке в WinRE система обрабатывает этот XML и вместо штатного восстановления открывает командную строку с доступом к уже разблокированному тому BitLocker.

Ключевое условие для сценария без предварительного входа в систему: Microsoft Defender Offline Scan уже должен был запускаться хотя бы раз. Это создаёт нужную структуру recovery-раздела. Если этого не было, атакующему потребуется самому инициировать или воссоздать состояние Defender Offline Scan, что обычно требует дополнительного доступа.

Механика работы GreatXML:

1. Атакующий получает физический доступ к диску (или возможность смонтировать recovery-раздел).

2. Копирует подготовленный unattend.xml в корень recovery-раздела и размещает/подменяет связанные файлы в структуре Recovery, включая Recovery\WindowsRE\ReAgent.xml.

3. Инициирует перезагрузку в WinRE (например, через меню восстановления).

4. WinRE обрабатывает unattend.xml, выполняет команды и открывает командную строку.

5. На системах с TPM-only BitLocker том уже разблокирован — доступ к файловой системе получен.

Результат: Командная строка с доступом к расшифрованным данным. Можно копировать файлы, менять настройки или ставить вредоносное ПО с привилегиями SYSTEM в среде восстановления.

GreatXML оставляет в телеметрии Windows крайне мало следов, потому что эксплуатация происходит до старта ОС. Но можно посмотреть на косвенные признаки:

GreatXML сложно детектировать событиями. Основной упор — на организационные меры и физическую безопасность. В отличие от YellowKey, здесь нужен хотя бы один запуск Defender Offline Scan, создающий необходимые файлы и директории, что немного сужает круг уязвимых систем.

RoguePlanet

RoguePlanet (CVE-2026-50656)— LPE-уязвимость в Microsoft Defender, основанная на TOCTOU race condition при обработке файлов во время очистки (cleanup). Атакующий подсовывает Defender файл-приманку, инициирует сканирование и очистку, а затем во время этой операции меняет файловую топологию через junction (точку соединения) и использует альтернативные потоки данных (ADS) и теневые копии (VSS) для точной синхронизации. Defender, работая в контексте SYSTEM, продолжает работать с именем, которое уже проверил, но реальный объект за этим именем становится другим. В результате подменённый файл запускается через штатную задачу Windows Error Reporting от SYSTEM.

Механика работы RoguePlanet:

1. Подготовка рабочего каталога и структуры

Эксплойт создаёт рабочий каталог с поддельным системным путём вида:

%TEMP%\RP_<GUID>\System32\wermgr.exe

Также создаётся промежуточный каталог wdtest_temp, который используется в race condition.

После этого монтируется встроенный ISO-образ (без назначения буквы диска), из которого извлекается легитимный файл wermgr.exe, используемый в качестве приманки для Microsoft Defender. К файлу добавляется альтернативный поток данных (ADS) :WDFOO, который впоследствии используется для синхронизации через VSS.

2. Инициация сканирования и очистки

Через библиотеку Mpclient.dll эксплойт вызывает функции MpScanStart, MpScanResult, MpCleanOpen и MpCleanStart. В результате Microsoft Defender получает файл-приманку и начинает его обработку с привилегиями SYSTEM.

3. Гонка: переключение файловой топологии с использованием VSS и ADS

Для синхронизации этапов очистки эксплойт использует теневые копии (VSS). Он открывает файл через HarddiskVolumeShadowCopy* по пути, содержащему альтернативный поток данных (ADS):

...\wermgr.exe:WDFOO

и устанавливает на него batch oplock, чтобы зафиксировать момент обращения Defender к файлу.

Параллельно эксплойт изменяет объект, на который указывает путь

%TEMP%\RP_*\System32\wermgr.exe

Для этого поочерёдно используются смонтированный ISO-образ, временный каталог, directory junction на C:\Windows, а также переименование каталогов. В результате Defender продолжает работать с уже известным именем файла, тогда как пользовательский процесс незаметно подменяет объект, на который это имя ссылается.

4. Запуск подменённого файла через Windows Error Reporting

После успешной подмены эксплойт запускает штатную задачу

\Microsoft\Windows\Windows Error Reporting\QueueReporting

В результате Windows Error Reporting (WER) запускает процесс

wermgr.exe -upload

от имени NT AUTHORITY\SYSTEM с родительским процессом svchost.exe.

5. Получение SYSTEM shell в интерактивной сессии

Если процесс уже выполняется с привилегиями SYSTEM, эксплойт подключается к именованному каналу

\\.\pipe\RoguePlanet

получает идентификатор пользовательской сессии, дублирует SYSTEM-токен и запускает conhost.exe. В результате атакующий получает полноценную командную строку с привилегиями SYSTEM.

Ключевые артефакты RoguePlanet

Ниже приведён пример корреляционного фильтра на языке VRL, который выявляет создание поддельного wermgr.exe и обращение к альтернативному потоку данных ADS :WDFOO.

.device_vendor == "microsoft" &&.device_product == "windows" &&.device_event_id == "11" &&(  (    dst_file_name == "wermgr.exe" &&    contains(dst_file_path, "\\Temp\\RP_") &&    contains(dst_file_path, "\\System32\\")  ) ||  (    contains(dst_file_path, "\\Temp\\RP_") &&    contains(lowercase(dst_file_path), "wermgr.exe:wdfoo")  ))

RoguePlanet интересен тем, как использует Defender: пользовательский процесс подсовывает файл, сам инициирует очистку, а затем во время очистки меняет файловые ссылки так, чтобы привилегированная операция сработала уже на другом объекте. Классический TOCTOU, но с нестандартным применением — вместо того чтобы ждать, пока Defender сам просканирует файл, эксплойт принудительно вызывает сканирование через Mpclient.dll. Ключевыми точками для детектирования являются создание ADS :WDFOO, использование VSS, монтирование ISO и установка junction. Уязвимость была исправлена со стороны вендора в рамках обновления движка Microsoft Malware Protection Engine до версии 1.1.26060.3008.

Выводы

Активность Microsoft Defender часто воспринимается как заведомо легитимная, поэтому события, связанные с его работой, нередко остаются вне поля зрения специалистов по мониторингу. Однако рассмотренные PoC показывают, что механизмы самого антивируса могут становиться частью цепочки атаки: использоваться для повышения привилегий, обхода защитных механизмов или нарушения работы средства защиты.

Именно поэтому события, связанные с работой Defender, стоит рассматривать не только как системную активность, но и как потенциальные индикаторы компрометации. Мониторинг нетипичных операций, контроль целостности критических файлов и корреляция событий, связанных с обновлением и работой антивируса, позволяют обнаружить подобные атаки на ранних этапах.

В этом небольшом цикле статей мы разобрали все публичные PoC, доступные на момент публикации и представленные исследователем Nightmare Eclipse. Однако, судя по его анонсам, исследования в этой области продолжаются, а значит, вполне вероятно появление новых способов эксплуатации Microsoft Defender. Поэтому механизмы защиты и правила обнаружения подобных техник также должны регулярно обновляться.

Источники

• BlueHammer: https://git.projectnightcrawler.dev/NightmareEclipse/BlueHammer
   

• RedSun: https://git.projectnightcrawler.dev/NightmareEclipse/RedSun
   

• UnDefend: https://git.projectnightcrawler.dev/NightmareEclipse/UnDefend
   

• GreatXML: https://git.projectnightcrawler.dev/NightmareEclipse/GreatXML
   

• RoguePlanet: https://git.projectnightcrawler.dev/NightmareEclipse/RoguePlanet
   

• Huntress: «Nightmare-Eclipse Tooling Seen in Real-World Intrusion»
   

• BleepingComputer: «Microsoft Defender ‘RoguePlanet’ zero-day grants SYSTEM privileges» 
   

• SecurityWeek: «Microsoft Tries to Calm Legal Threat Fears After Zero-Day Disclosure Backlash»
   

• The Hacker News: «Microsoft Warns of Two Actively Exploited Defender Vulnerabilities»
   

• ThreatLocker: «GreatXML: Exploiting the WinRE trust boundary behind BitLocker»