Одним из самых опасных моментов апреля стала публикация рабочего эксплойта для Windows Defender.
CISA добавила CVE-2026-33825 в каталог Known Exploited Vulnerabilities после публичного выпуска рабочего proof-of-concept. Организациям, использующим Microsoft Defender Antimalware Platform версий до 4.18.26020.6, следует немедленно установить исправление.
Предпосылки: предел терпения исследователя
2 апреля 2026 года исследователь безопасности, действующий под псевдонимом Chaotic Eclipse, публично обнародовал BlueHammer. Это полностью функциональный proof-of-concept эксплойта для локального повышения привилегий в Windows. Публикация не была запланирована, скоординирована или проведена в рамках какого-либо процесса ответственного раскрытия. Как утверждается, в конце концов это стало проявлением разочарования процессом сообщения об уязвимости в Microsoft.
Последствия были мгновенными. BlueHammer появился на GitHub и форумах по безопасности. Его быстро проанализировали, адаптировали для практического использования в атаках и добавили в инструментарий злоумышленников. В течение двух недель после начальной публикации Chaotic Eclipse обнародовал еще две уязвимости Microsoft Defender под названиями RedSun и UnDefend. Это существенно продлило период повышенного риска.
Особое внимание в BlueHammer привлекает его утонченность. Эксплойт объединяет несколько доверенных подсистем Windows таким образом, что традиционное обнаружение становится крайне сложным.
CVE-2026-33825: Microsoft Defender Antimalware Platform – повышение привилегий
Локальный злоумышленник с низкими привилегиями может повысить их до уровня NT AUTHORITY\SYSTEM. Для этого он злоупотребляет доверенным процессом обработки файлов в Microsoft Defender и получает произвольный дескриптор чтения к базе данных SAM. Пораженные версии: Microsoft Defender Antimalware Platform до 4.18.26020.6.
Цепочка атаки: шаг за шагом
BlueHammer лучше всего рассматривать как многоэтапный эксплойт, злоупотребляющий неявным доверием Windows к собственным процессам безопасности. Каждый его этап спроектирован так, чтобы выглядеть доверенным. И в значительной степени он действительно воспринимается как доверенный (по крайней мере с точки зрения ядра).
Шаг 1: разведка по обновлению
Эксплойт начинает работу с загрузки доверенного содержимого обновлений Microsoft Defender из CDN Microsoft. Это создает неподозрительный контекст исполнения. Благодаря этому следующие этапы выглядят как часть обычного процесса обновления сигнатур.
Шаг 2: запуск Defender и создание теневой копии
Тестовый файл EICAR размещается в системе, чтобы спровоцировать активность сканирования Defender. Одновременно размещается RstrtMgr.dll из batch oplock, который используется как временной маркер. Рабочий поток отслеживает появление новых объектов HarddiskVolumeShadowCopy. Это подтверждает, что Defender вошел в целевой рабочий процесс и новый снимок VSS готов.
Шаг 3: приостановка работы Defender через Cloud Files API
Рабочий каталог регистрируется как поддельный корень облачной синхронизации с помощью CfRegisterSyncRoot и CfConnectSyncRoot. Эти API обычно используются OneDrive и подобными сервисами. Внутри размещается файл .lock. Когда Defender обращается к нему, срабатывает callback CfCallbackFetchPlaceHolders. Он проверяет, что вызовом управляет служба WinDefend, и удерживает Defender в приостановленном состоянии с помощью скоординированного batch oplock. Так создается точное временное окно.
Шаг 4: Гонка TOCTOU – перенаправление в базу данных SAM
Пока Defender находится в приостановленном состоянии, эксплойт запускает механизм обновления Defender с помощью доверенных файлов. Когда Defender создает новый каталог определений и обрабатывает mpasbase.vdm, эксплуатируется состояние гонки Time-of-Check to Time-of-Use (TOCTOU). Указанный путь подменяется так, чтобы Defender открыл базу данных SAM внутри теневой копии вместо ожидаемого файла обновления.
Шаг 5: извлечение учетных данных из SAM
Получив дескриптор чтения к кусту SAM, эксплойт реконструирует ключ загрузки Windows из HKLM\SYSTEM\CurrentControlSet\Control\Lsa. После этого он расшифровывает материал шифрования паролей SAM и восстанавливает локальные NTLM-хеши.
Шаг 6: запуск SYSTEM shell и заметание следов
Восстановленные хеши NTLM используются для временного изменения пароля учетной записи локального администратора. Временная служба Windows повторно запускает PoC от имени NT AUTHORITY\SYSTEM. В текущем сеансе пользователя запускается консоль SYSTEM. После этого исходный пароль восстанавливается с помощью восстановленного хеша. Учетные пользовательские данные остаются неизменными, а атака – в значительной степени незаметной.
Почему традиционное обнаружение не срабатывает
Опасность BlueHammer состоит в том, что на каждом шаге он использует доверенные составляющие Windows. Эксплойт не записывает новые вредоносные бинарные файлы. Он не вызывает явно подозрительные API изолированно. Он злоупотребляет неявным доверием, которое операционная система предоставляет собственным компонентам безопасности.
Механизм обновления Defender, служба Volume Shadow Copy Service и Cloud Files API являются доверенными, подписанными компонентами. Их работа с повышенными привилегиями ожидаема. Организуя цепочку легитимных взаимодействий, BlueHammer создает путь для повышения привилегий. Статические инструменты анализа и традиционные поведенческие правила плохо приспособлены для его выявления.
Сложная проблема: три уязвимости за две недели
Если бы история ограничивалась только BlueHammer, этого уже было бы достаточно для серьезного беспокойства. Но в течение 14 дней после публикации BlueHammer Chaotic Eclipse обнародовал еще две уязвимости Defender: RedSun и UnDefened. Такая быстрая последовательность создала необычную ситуацию. Команды защиты пытались срочно закрыть одну активно эксплуатируемую уязвимость, тогда как еще два публичных эксплойта уже распространялись.
Эта схема отражает известный, но недооцененный риск в ответственном раскрытии уязвимостей. Когда исследователи разочаровываются сроками реагирования вендора, неформальные нормы скоординированного раскрытия могут быстро разрушаться. В результате возникает асимметричная информационная среда. Злоумышленники получают доступ к рабочим эксплойтам, тогда как команды безопасности все еще оценивают влияние.
Смягчение риска
Microsoft Defender Antimalware Platform следует обновить до версии 4.18.26030.3011. Это обновление поставляется через Windows Update и обновление платформы Microsoft Defender.
Для организаций со средами обновления, управляемыми через WSUS или SCCM, следует определить это обновление платформы как приоритетное для ускоренного развертывания. Не стоит полагаться только на проверки обновлений сигнатур. Пораженным компонентом является версия платформы Defender, а не база определений.
Следует отслеживать индикаторы компрометации, в частности, неожиданные события создания теневых копий томов, необычное взаимодействие процессов с VSS, а также любые предупреждения о локальном повышении привилегий от платформ обнаружения на конечных устройствах.
Для усиления обнаружения и реагирования на конечных устройствах можно использовать Cynet. XDR платформа помогает командам безопасности централизованно анализировать события на уровнях endpoint, network, identity и cloud, а также автоматизировать расследование и реагирование на угрозы. Если вы хотите получить бесплатную пробную версию Cynet, оставьте свои контактные данные в форме ниже и наша команда свяжется с вами.
