Хабр, привет! На связи Александр Бек, аналитик‑исследователь угроз кибербезопасности R—Vision.

В 2026 году исследователь Nightmare Eclipse, известный также под псевдонимами Chaotic Eclipse, MSNightmare и Dead Eclipse, опубликовал серию PoC‑эксплойтов для уязвимостей нулевого дня. Сначала его работы были посвящены продуктам Microsoft, затем он обратился к стороннему ПО, в том числе к средствам защиты.

В сентябре исследователь назвал себя Абдельхамидом Насери (Abdelhamid Naceri) и связал свои публикации с конфликтом с бывшим работодателем, Microsoft.

Несмотря на личный характер мотивации автора, его технические работы представляют значительный интерес для специалистов по безопасности. Они демонстрируют не только эксплуатацию уязвимостей, но и изощрённые техники обхода доверенных процессов средств защиты. В фокусе моей статьи два эксплойта из этой серии: HardBreacher, нацеленный на Kaspersky Endpoint Security, и PrettyPrague, эксплуатирующий песочницу Avast Antivirus.

Мы детально разберём механику работы обоих PoC, выделим характерные низкоуровневые артефакты, которые они оставляют в системе, и на их основе сформулируем подходы к построению корреляционных правил обнаружения.

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

Общая сводная таблица

HardBreacher: компрометация Kaspersky Endpoint Security

HardBreacher — это PoC‑эксплойт, опубликованный Nightmare Eclipse 29 августа 2026 года и нацеленный на локальное повышение привилегий в Kaspersky Endpoint Security. Автор тестировал его на полностью пропатченной Windows 11 25H2 с Kaspersky Endpoint Security 14.0.0.504. Эксплойт нестабилен, часто завершается с ошибкой и требует многократных запусков или перезагрузки, но при успехе приводит к созданию файла C:\Windows\System32\MY_SNAKE_IS_SOLID.dll с полными правами для текущего пользователя.

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

Шаг 1: Подготовка «теневого» дерева и hardlink

Эксплойт начинается с создания рабочей директории ...\Desktop\Kaspy\, внутри которой формируется поддельное дерево Windows\System32\. В это дерево помещается hardlink MY_SNAKE_IS_SOLID.dll, указывающий на безобидную картинку mrkaspy.jpg. Как отмечают в анализе LevelBlue, файл‑приманка и DLL, размещённая в фейковом System32, имеют идентичный SHA-256 — это два имени, указывающие на один и тот же inode через NTFS hardlink. Сам по себе этот шаг не требует привилегий: hardlink создаётся в пользовательской директории.

Шаг 2: Подмена пути через DosDevices

Каждая сессия входа Windows имеет собственный каталог объектов в пространстве имён ядра — \Sessions\0\DosDevices\{AuthId}\. Обычный пользовательский процесс может без специальных привилегий создавать символические ссылки внутри этого каталога. Если создать там ссылку с именем C:, то все пути, начинающиеся с C:\, в этой сессии будут разрешаться через эту ссылку, затеняя глобальное пространство имён устройств.

HardBreacher создаёт каталог KASPERSKY-{GUID}, содержащий символические ссылки на все настоящие файлы Kaspersky, за исключением avpuimain.dll — основной DLL, загружаемой UI‑процессом Kaspersky при старте. Симлинк для avpuimain.dll указывает на payload DLL, размещённую в %TEMP%.

Затем эксплойт создаёт перенаправление C: на подготовленный каталог, возобновляет поток avpui.exe и ждёт подтверждения от payload:

// Построение session-specific C: redirect на поддельное дерево
wsprintf(maindrvtarget, L"%ws\\%ws", currdosdv, ksdospath);
NtCreateSymbolicLinkObject(&hmaindrv, MAXIMUM_ALLOWED, &_maindrvobjattr, &_maindrvtarget);

// Возобновление avpui.exe — его загрузчик DLL теперь видит поддельный диск C:
ResumeThread(hThread);
WaitForSingleObject(hnotify, INFINITE); // ожидание подтверждения от payload
CloseHandle(hmaindrv); // немедленное удаление redirect

Как подчёркивает LevelBlue, перенаправление C: активно только в течение миллисекунд между ResumeThread и обратным вызовом payload, после чего немедленно удаляется, не оставляя постоянных изменений в пространстве имён.

Шаг 3: Подмена родительского процесса и запуск avpui.exe

Чтобы замаскировать происхождение процесса, HardBreacher подменяет его родительский процесс (PPID). В результате avpui.exe будет выглядеть как дочерний процесс explorer.exe. Для этого при создании процесса задаётся атрибут PS_ATTRIBUTE_PARENT_PROCESS, а сам процесс запускается в приостановленном состоянии:

AttributeList->Attributes[1].Attribute = PS_ATTRIBUTE_PARENT_PROCESS;
AttributeList->Attributes[1].ValuePtr = GetExplorerProcess(); // handle на explorer

// Запуск в suspended-состоянии — симлинк C: активируется до возобновления потока
NtCreateUserProcess(&hProcess, &hThread, MAXIMUM_ALLOWED, MAXIMUM_ALLOWED, NULL,
  NULL, NULL, THREAD_CREATE_FLAGS_CREATE_SUSPENDED, ProcessParameters,
  &CreateInfo, AttributeList);

Дерево процессов, записанное Windows и большинством EDR‑систем, показывает avpui.exe как дочерний процесс Проводника, как если бы пользователь запустил его обычным образом. Фактический процесс‑инициатор не оставляет родительского следа.

Шаг 4: Загрузка DLL и подавление уведомлений Kaspersky

Когда avpui.exe возобновляется, загрузчик ОС, «делая именно то, что должен», загружает DLL атакующего вместо легитимной avpuimain.dll. Payload (SolidSnake.dll`) выполняет две задачи:

1. Входит в цикл EnumWindows, ожидая появления окна с заголовком "Notification from Kaspersky Endpoint Security". Найдя его, скрывает всплывающее окно до того, как его увидит пользователь.

2. Через CreateToolhelp32Snapshot находит все процессы avpui.exe и завершает их через TerminateProcess с MAXIMUM_ALLOWED.

В конфигурации KES v14 по умолчанию avpui.exe не перезапускается автоматически, оставляя endpoint без пользовательского канала уведомлений до конца сессии. Сам автор описывает это так: «Kaspersky полностью теряет контроль, когда вы берёте под контроль UI‑процесс… вся операционная система превращается в хаос».

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

Пример корреляционного фильтра (VRL)

Процессы разработчика Kaspersky (и другие зависимости) по умолчанию всегда имеют валидную подпись на файлах. Таким образом загрузка антивирусом неподписанной DLL библиотеки должна не только указывать на потенциальную эксплуатацию уязвимости, но и предупредить о подготовке к другой возможной вредоносной активности, которая может привести к манипуляциям с АВПО.

filter: !vrl |
  (.device_vendor == "microsoft" && .device_product == "windows") &&
  (.device_event_id == "7") &&
  (rv_contains_any(src_process_path_full, [
    "\\program files\\kaspersky lab\\",
    "\\program files (x86)\\kaspersky lab\\"
  ])) &&
  (contains(dst_object_sign, "signed: false")) &&
  (ends_with(dst_object_name, ".dll"))

Фильтр не привязан к именам HardBreacher.exe или MY_SNAKE_IS_SOLID.dll. Он отбирает загрузку неподписанной DLL процессом, путь которого содержит один из указанных каталогов Kaspersky. единственным ограничением является обязательное указание путей или имен процессов (в нашем случае АВПО Kaspersky), являющихся критическими.

Именно поэтому детект переживёт изменения в коде эксплойта: даже если автор переименует бинарные файлы, изменит GUID или будет использовать другой процесс‑жертву, комбинация таких действий останется аномалией.

PrettyPrague: компрометация песочницы Avast и кража SAM

PrettyPrague — еще один PoC Nightmare Eclipse, опубликованный 30 августа 2026 года и нацеленный на локальное повышение привилегий в Avast Antivirus (Gen Digital). В отличие от HardBreacher, который манипулирует пространством имён объектов, PrettyPrague эксплуатирует механизм файловой виртуализации песочницы Avast, чтобы вытащить базу SAM и получить SYSTEM‑шелл. Автор утверждает, что PoC совместим с любой версией Avast и работает на полностью пропатченной Windows 11 25H2. Gen Digital подтвердила уязвимость и выпустила исправление в версиях 26.7.11086 и 26.8.11125.

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

Шаг 1: Регистрация в песочнице Avast

Песочница Avast виртуализирует файловые операции через пользовательский перехватчик snxhk.dll и драйвер ядра aswSnx.sys. Для входа в песочницу PrettyPrague открывает устройство \\.\aswSnx — это интерфейс для связи с драйвером Avast — и посылает ему IOCTL‑команду 0x82AC0054, указав путь к собственному исполняемому файлу. Драйвер воспринимает это как просьбу поместить процесс в песочницу.

HANDLE hsnx = CreateFile(L"\\\\.\\aswSnx", GENERIC_READ, ...);
char buff[0x1028] = { 0 };
buff[0] = 0x1 | 0x20;
wcscpy((wchar_t*)&buff[2074], sbxapp);
memmove(&buff[24], &hsbx, sizeof(hsbx));
DeviceIoControl(hsnx, 0x82AC0054, buff, sizeof(buff), ...);

Драйвер помечает процесс как участника песочницы. Все дочерние процессы, порождённые с этого момента, наследуют контекст песочницы.

Шаг 2: Создание копии SAM внутри песочницы

Avast внедряет snxhk.dll в дочерний процесс. PrettyPrague проверяет наличие этой DLL через GetModuleHandle и переключается в ветку SandboxedMain. Внутри песочницы создаётся приостановленный рабочий поток, который должен запросить доступ к защищённому кусту реестра SAM.

DWORD WINAPI Worker(void*) {
    HANDLE hfile = CreateFile(
        L"C:\\Windows\\System32\\config\\SAM",
        GENERIC_READ | FILE_WRITE_DATA,
        FILE_SHARE_READ | ...
    );

    return ERROR_SUCCESS;
}

Пока поток приостановлен, родительский процесс настраивает наблюдение за каталогом C:\avast! sandbox\ через ReadDirectoryChangesW, затем возобновляет поток. Запрос на запись в логический путь SAM внутри песочницы приводит к появлению файла, созданного на основе SAM в C:\avast! sandbox\.

Шаг 3: Изменение прав доступа к копии SAM

Когда файл появляется, PrettyPrague ослабляет права на директории, чтобы сделать копию доступной для чтения извне песочницы:

ea.grfAccessPermissions = FILE_ALL_ACCESS;
ea.Trustee.ptstrName = (LPWSTR)pEveryoneSID; // Everyone

SetEntriesInAclW(1, &ea, NULL, &pAcl);
NtSetSecurityObject(hcfgdir, DACL_SECURITY_INFORMATION, pSD);

Сам оригинальный SAM остаётся заблокированным. Avast создаёт его виртуализированную копию, которую PoC и читает.

Шаг 4: Транзакционное копирование и расшифровка

Копия SAM копируется в C:\Windows\Temp\<GUID> через транзакцию NTFS (CreateFileTransacted) — это обходит файловую виртуализацию, так как операция выглядит как транзакционная запись. Затем offreg.dll открывает хайв напрямую, извлекаются LSA‑секреты (JD, Skew1, GBG, Data), расшифровываются NTLM‑хеши пользователей.

Шаг 5: Временная смена пароля и создание службы

Для каждого пользователя с непустым NTLM‑хешем (кроме текущего и WDAGUtilityAccount) PrettyPrague:

1. Временно меняет пароль на PRETTY_PRAGUE через SamiChangePasswordUser из samlib.dll.

2. Выполняет вход под этой учётной записью через LogonUserEx с LOGON32_LOGON_INTERACTIVE.

3. Повышает целостность токена до S-1-16-8192 (System) и создаёт временную службу с GUID‑именем, которая запускает сам эксплойт от SYSTEM.

4. Восстанавливает исходный пароль.

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

Пример корреляционного правила (VRL)

Предлагаемая корреляция связывает два события на одном хосте: загрузку перехватчика Avast и программный вход под другой учётной записью. Во втором событии дополнительно проверяется путь к процессу.

Первое событие — загрузка snxhk.dll в процесс.

filter: !vrl |
  .device_event_id == "7" &&
  contains_all(dst_object_path_full, ["\\avast", "\\snxhk.dll"]) &&
  contains(dst_object_sign, "gen digital inc")

Второе событие — программный вход под другой учётной записью.

filter: !vrl |
  (.device_event_id == "4624") &&
  (logon_type == "interactive" || logon_type == "batch") &&
  (dst_object_name == "advapi") &&
  (contains(src_process_path_full, "\\users\\") ||
   contains(src_process_path_full, "\\temp\\")) &&
  (.src_user_name != .dst_user_name)

Имена исполняемых файлов и зависимости запускаемого эксплоита не входят в приведённые фильтры, поэтому их замена в исходном коде PrettyPrague не меняет условия отбора. События связываются по одинаковым значениям имени устройства, пользователя‑инициатора и имени процесса‑источника в пределах 5 секунд для более точной фильтрации событий и исключения False‑Positive сработок.

Также, как и в случае с HardBreacher, корреляционное правило не привязано к имени PrettyPrague.exe или другим динамическим зависимостям эксплоита. Оно ловит структурную аномалию: процесс из пользовательской директории загружает подписанный перехватчик Avast и затем выполняет программный вход под другим пользователем через Advapi.

В PrettyPrague доступ к защищённым данным появляется через механизм файловой виртуализации Avast. Дальнейшие действия включают временную смену пароля, вход под другой учётной записью и создание службы. Корреляция загрузки перехватчика с последующим входом охватывает часть этой цепочки; остальные события помогают проверить гипотезу при расследовании.

Выводы

Nightmare Eclipse за несколько недель опубликовал еще множество эксплоитов, которые осталась за рамками статьи:

• ShieldCrash — реинкарнация RoguePlanet и ShieldBreak, обход патча в Microsoft Defender;

• GreenSection — повреждение памяти в пользовательских компонентах драйверов NVIDIA, приводящее к сбою приложений;

• FalconFlank — повышение привилегий через TOCTOU‑гонку в CrowdStrike Falcon;

• LegacyHive — загрузка чужих реестровых кустов через User Profile Service;

• BigDiskBuster — DoS системы автоматических обновлений Defender.

Этот перечень показывает, что автор сейчас фокусируется на поиске слабых мест не в самой операционной системе, а в ПО, которое её защищает.

HardBreacher и PrettyPrague используют разные механизмы средств защиты. В первом случае интерес для обнаружения представляет загрузка неподписанной DLL процессом Kaspersky, во втором — связь загрузки перехватчика Avast с входом под другой учётной записью.

В этой статье мы хотели показать важность скрупулёзного анализа работы инструментов атакующих, сейчас как никогда просто изменить уже существующие образцы из публичного доступа (даже без исходного кода), поэтому важно не просто отслеживать имена файлов, а выстраивать корреляцию на межпроцессных взаимодействиях, происходящих в системе. Это позволит как детектировать использование модифицированных эксплоитов, так и заранее предвидеть возможные аномалии, которые раньше не были замечены в инфополе.