Средний

10 мин

339

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

На связи Владимир Шнейдмюллер, аналитик-исследователь угроз кибербезопасности R-Vision.

Вокруг Nightmare Eclipse за последние недели успело сложиться почти всё, что обычно сопровождает громкие публичные zero-day: резкие заявления автора, споры о такой практике раскрытия, быстрые проверки PoC сообществом, первые форки и закономерный вопрос - что из этого можно увидеть в телеметрии, а что останется почти полностью за пределами SIEM?

Мы разобрали несколько опубликованных PoC и в этой статье начнем с первых трёх: YellowKey, GreenPlasma и MiniPlasma. Они существенно различаются как по векторам атак, так и по возможностям обнаружения. YellowKey интересен как обход BitLocker через WinRE, но почти не оставляет удобных событий в ОС. GreenPlasma демонстрирует низкоуровневый примитив на стыке CTF/Winlogon и Windows Object Manager. MiniPlasma, наоборот, уже дает практический сценарий локального повышения привилегий, где можно строить вполне рабочие детекты по реестру, файловой системе и запуску процессов.

Ниже не будет пошаговой инструкции по эксплуатации. Нас интересуют механика, артефакты и точки наблюдения, которые полезны SOC и threat hunting-командам.

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

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

В этой части разберём три PoC:

YellowKey: BitLocker bypass

YellowKey заявлен как обход BitLocker через Windows Recovery Environment. Для него зарегистрирован CVE-2026-45585, хотя сама регистрация, судя по публичным материалам, была сделана не автором PoC.

Сценарий сводится к тому, что атакующий получает интерактивный cmd.exe в WinRE с доступом к системному тому, который уже был разблокирован BitLocker.

Проблема не в самой криптографии BitLocker. PoC использует то, как WinRE при старте обрабатывает служебные журналы Transactional NTFS/FsTx. В среде восстановления есть утилита FsTx Auto Recovery Utility (autofstx.exe): она ищет такие журналы и пытается автоматически их восстановить. Если заранее положить подготовленные данные в System Volume Information\FsTx, WinRE может пойти не по штатному сценарию восстановления.

Если совсем коротко, цепочка выглядит так:

1. Атакующий готовит System Volume Information\FsTxна носителе или разделе, который будет виден при входе в WinRE.

2. Устройство загружается в Windows Recovery Environment.

3. autofstx.exe обрабатывает найденные FsTx-журналы.

4. Вместо обычного сценария восстановления появляется cmd.exe.

5. На конфигурации только с TPM системный том к этому моменту уже может быть разблокирован, поэтому shell получает доступ к данным.

То есть диск не расшифровывается подбором ключа и BitLocker не ломается как алгоритм. Атака использует состояние, в котором Windows уже открыла защищенный том для recovery-сценария, но вместо ограниченного интерфейса восстановления пользователь получает командную строку.

Что можно увидеть

Эксплуатация происходит до нормальной загрузки Windows и внутри WinRE. Поэтому классическая хостовая телеметрия почти бесполезна.

Потенциальные косвенные признаки:

Но это именно косвенные признаки. Они не доказывают эксплуатацию YellowKey. Пользователь мог подключить флешку и штатно уйти в восстановление системы.

YellowKey плохо ложится в классический SIEM-детект. Основные меры здесь ближе к харденингу и контролю физического доступа: TPM+PIN для BitLocker, контроль WinRE/autofstx.exe по рекомендациям Microsoft, запрет загрузки с внешних устройств, пароль на BIOS/UEFI и мониторинг recovery boot на уровне EDR/MDM, где это возможно.

GreenPlasma: CTF/Winlogon и опасный примитив

GreenPlasma - это демонстрация примитива. Автор прямо указывает, что из опубликованного кода убран финальный этап, который превращает технику в полноценный SYSTEM shell

Главная идея GreenPlasma - пользовательский процесс заранее создает объект в пространстве имен Windows Object Manager по пути, который ожидают использовать CTF/Winlogon-компоненты. После этого PoC провоцирует обращение со стороны системной части Windows и получает section object, то есть объект разделяемой памяти.

Цепочка такая:

1. PoC узнает номер текущей интерактивной сессии.

2. В этой сессии он заранее занимает CTF-имя, которое связано с Winlogon/secure desktop.

3. Затем запускает UAC-сценарий через conhost.exe с runas, чтобы Windows задействовала CTF-компоненты.

4. Когда CTF/Winlogon обращается к ожидаемому имени, он попадает на подготовленный PoC объект.

5. PoC получает handle на section object. А это уже примитив для дальнейшей эксплуатации.

В нашей лаборатории был подтвержден объект вида:

\Sessions\<SessionId>\BaseNamedObjects\CTF.AsmListCache.FMPWinlogon<SessionId>

Также фигурирует путь:

\BaseNamedObjects\CTFMON_DEAD

Обычный пользователь не должен иметь возможности заранее подменять или занимать имена объектов, с которыми потом работает более доверенный компонент. Если привилегированный процесс открывает объект по предсказуемому пути, а этот путь частично контролируется пользователем, появляется примитив для дальнейшей эксплуатации.

Механика

PoC сначала определяет текущий SessionId. CTF/Winlogon-объекты находятся не в глобальном пространстве, а внутри пространства конкретной интерактивной сессии:

\Sessions\<SessionId>\BaseNamedObjects\...

Затем через NtCreateSymbolicLinkObject PoC заранее занимает имя:

\Sessions\<SessionId>\BaseNamedObjects\CTF.AsmListCache.FMPWinlogon<SessionId>

и указывает, куда это имя должно вести. Если аргумент не передан, цель по умолчанию - \BaseNamedObjects\CTFMON_DEAD.

После этого PoC запускает conhost.exe через ShellExecuteEx с параметром runas. Нужен не сам conhost.exe, а эффект от запуска: Windows показывает UAC/secure desktop, а вместе с ним включается CTF-инфраструктура, связанная с вводом текста и Winlogon. В этот момент системные компоненты начинают работать с CTF-объектами текущей сессии.

Дальше PoC просто ждёт, когда по подготовленному имени появится section object. Для этого он в цикле вызывает NtOpenSection. Успешное открытие означает, что Windows создала или открыла объект разделяемой памяти по имени, которое заранее подготовил пользовательский процесс.

Разделяемая память может использоваться для передачи структур, параметров или состояния между процессами. Если один из потребителей работает в более привилегированном контексте и доверяет данным из такого объекта, появляется путь к LPE.

Реестровый хвост GreenPlasma

Отдельная часть PoC связана с Cloud Files и registry symbolic link abuse. В ходе выполнения затрагивается ветка:

HKCU\Software\Policies\Microsoft\CloudFiles\BlockedApps

В коде используется cldapi.dll и вызов CfAbortOperation, после чего PoC создает registry link. В лабораторной телеметрии появлялось значение SymbolicLinkValue, указывающее на:

HKCU\Software\Microsoft\Windows\CurrentVersion\Policies\System

Также устанавливалось значение:

DisableLockWorkstation = 1

С точки зрения детекта это уже намного полезнее, чем чистые Object Manager-артефакты. Большинство SIEM и EDR не видят создание NtCreateSymbolicLinkObject напрямую, зато можно опираться на Sysmon Event ID 13.

На что смотреть

Полезные артефакты GreenPlasma:

Пример VRL-фильтра:

.device_vendor == "microsoft" &&
 .device_product == "windows" &&
 .device_event_id == "13" &&
 ends_with(dst_object_path_full, "\\software\\policies\\microsoft\\cloudfiles\\blockedapps\\symboliclinkvalue")

Ложные срабатывания возможны вокруг Cloud Files, OneDrive, Office, FileCoAuth и MDM/Intune-политик. Поэтому CloudFiles\BlockedApps сам по себе лучше не считать инцидентом.

Вывод               

GreenPlasma  показывает как пользовательский процесс может заранее подготовить имя объекта, с которым потом работает CTF/Winlogon-механика.

Для детекта это неудобный сценарий. Обычный SIEM чаще всего не видит вызовы вроде NtCreateSymbolicLinkObject и NtOpenSection. Поэтому практичнее смотреть на то, что остаётся в доступной телеметрии: изменения CloudFiles\BlockedApps, появление SymbolicLinkValue и необычную активность вокруг UAC/secure desktop. Если EDR умеет показывать операции с Object Manager, тогда уже можно пойти глубже и проверять CTF-пути напрямую.

MiniPlasma: когда примитив превращается в SYSTEM shell

MiniPlasma - самый практичный PoC из этой тройки. Он берет идею Cloud Files, знакомую по GreenPlasma и старому исследованию James Forshaw из Google Project Zero, и доводит её до понятного результата,  где штатная задача Windows Error Reporting запускает подконтрольный файл от NT AUTHORITY\SYSTEM.

Идея эксплуатации довольно элегантная. В нормальном сценарии задача Windows Error Reporting QueueReporting запускает:

C:\Windows\System32\wermgr.exe -upload

MiniPlasma добивается того, что для системного контекста переменная %windir% начинает указывать не на C:\Windows, а на каталог PoC. После этого путь превращается в:

<каталог PoC>\System32\wermgr.exe -upload

То есть PoC создаёт собственный каталог System32 рядом с собой, копирует туда свой исполняемый файл под именем wermgr.exe, а затем заставляет штатный механизм WER запустить именно его.

Цепочка MiniPlasma выглядит так:

1. PoC использует Cloud Files/registry link abuse, чтобы добраться до .DEFAULT\Volatile Environment.

2. В .DEFAULT меняется значение windir: вместо C:\Windows оно указывает на каталог PoC.

3. Рядом с PoC создается поддельный System32\wermgr.exe.

4. Запускается штатная задача Windows Error Reporting QueueReporting.

5. WER берет путь через %windir% и запускает поддельный wermgr.exe от SYSTEM.

Механика

PoC запускает несколько стадий, чтобы разнести race condition и последующие действия по разным процессам. В одной стадии используется cldapi.dll и CfAbortOperation, параллельно поток постоянно ставит и снимает anonymous impersonation token.

Здесь PoC цепляется за логику Cloud Files, которая проверяет политики заблокированных приложений. Когда Windows работает с cloud placeholder-файлами, то есть локальными заглушками файлов из облачного хранилища, она обращается к CloudFiles\BlockedApps, чтобы понять, нужно ли блокировать доступ конкретному процессу. За счет гонки с impersonation token и registry symbolic link PoC добивается того, что эта логика начинает работать с перенаправленным путем в .DEFAULT, а не с обычной пользовательской веткой.

Дальше создается registry symbolic link:

\Registry\User\.DEFAULT\Software\Policies\Microsoft\CloudFiles\BlockedApps
    -> \Registry\User\.DEFAULT\Volatile Environment

После этого PoC записывает:

HKU\.DEFAULT\Volatile Environment\windir = <каталог PoC>

Затем создаёт файл:

<каталог PoC>\System32\wermgr.exe

И запускает штатную задачу:

\Microsoft\Windows\Windows Error Reporting\QueueReporting

Родителем процесса в телеметрии будет svchost.exe службы Schedule, а пользователь - NT AUTHORITY\SYSTEM.

На что смотреть

MiniPlasma оставляет очень интересную цепочку:

1. Изменениe CloudFiles\BlockedApps.

2. Запись HKU\.DEFAULT\Volatile Environment\windir в нетипичное значение.

3. Создание поддельного System32\wermgr.exe вне C:\Windows.

4. Запуск wermgr.exe от SYSTEM не из настоящего системного каталога.

5. Родительский процесс svchost.exe со службой Schedule.

6. Командная строка wermgr.exe -upload.

Основной сигнал - запуск wermgr.exe от SYSTEM из пути, который не начинается с C:\Windows\System32\ или C:\Windows\SysWOW64\.

Пример условия для детекта:

.device_event_id == "1" &&
 dst_process_name == "wermgr.exe" &&
 src_process_parent_name == "svchost.exe" &&
 contains(src_process_parent_cmdline, "-s schedule") &&
 !rv_contains_any(dst_process_path_full, [":\\windows\\system32\\", ":\\windows\\syswow64\\"])

Полезные события:

Вывод

Cloud Files и BlockedApps могут встречаться в легитимной активности OneDrive, Office или MDM. Но запуск wermgr.exe от SYSTEM из пользовательского каталога - это уже не нормальное поведение.

Практические выводы

Первые три PoC Nightmare Eclipse показывают три разных уровня удобства для защитника.

YellowKey опасен, потому что работает вокруг WinRE и BitLocker, но почти не оставляет удобной телеметрии в загруженной Windows. Здесь важнее харденинг, физическая безопасность и контроль сценариев восстановления.

GreenPlasma показывает низкоуровневый примитив, который может быть развит в LPE. Его сложно ловить напрямую без хорошей EDR-телеметрии по Object Manager, но можно искать сопутствующие изменения Cloud Files, registry symbolic link abuse и необычные CTF/Winlogon-артефакты.

MiniPlasma уже является практичной цепочкой повышения привилегий. Он меняет .DEFAULT\Volatile Environment\windir, создает поддельный System32\wermgr.exe и запускает его через штатную задачу Windows Error Reporting от SYSTEM.

Источники

• Nightmare Eclipse / YellowKey: https://git.projectnightcrawler.dev/NightmareEclipse/YellowKey

• Nightmare Eclipse / GreenPlasma: https://git.projectnightcrawler.dev/NightmareEclipse/GreenPlasma

• Nightmare Eclipse / MiniPlasma: https://git.projectnightcrawler.dev/NightmareEclipse/MiniPlasma

• Google Project Zero issue 2051: https://project-zero.issues.chromium.org/issues/42451192

• MSRC CVE-2020-17103: https://msrc.microsoft.com/update-guide/vulnerability/CVE-2020-17103

• The Register: https://www.theregister.com/security/2026/05/13/disgruntled_researcher_releases_two_more_microsoft_zero_days/5239758

• SecurityWeek: https://www.securityweek.com/researcher-drops-yellowkey-greenplasma-windows-zero-days/