Windows Defender как таран: три 0-day за 13 дней и два из них всё ещё без патча

За две недели апреля 2026-го один анонимный исследователь выложил в открытый доступ три рабочих эксплойта против Microsoft Defender. Все три позволяют обычному пользователю без прав администратора получить SYSTEM. Два из них на момент публикации этого текста всё ещё без патча, и Huntress уже ловит их в реальных атаках.

Самое неприятное: в двух случаях антивирус используют не как цель обхода, а как инструмент доставки. Defender сам, со своими SYSTEM-правами, пишет вредоносный файл в C:\Windows\System32 — потому что ему так сказали.

Ниже — что именно произошло, почему это работает и что с этим делать, если у вас парк Windows-машин.

Бэкграунд: как три 0-day попали в паблик

3 апреля на GitHub появился PoC BlueHammer — LPE для Windows Defender, который позволяет с обычного юзера уйти в SYSTEM. Автор — некий Chaotic Eclipse (он же Nightmare-Eclipse). По его словам, отчёт в MSRC ушёл заранее, но процесс застопорился: Microsoft требовала видео-демонстрацию, исследователь отказался, кейс закрыли. Публикация PoC стала демонстративным ответом.

Microsoft закрыла BlueHammer в рамках апрельского Patch Tuesday 14 апреля — это CVE-2026-33825, CVSS 7.8. От публикации до патча прошло 11 дней. Huntress видел эксплуатацию в дикой природе уже 10 апреля, то есть за четыре дня до патча.

12 апреля в тот же репозиторий лёг второй PoC — UnDefend. Это не LPE, а DoS против самого Defender.

16 апреля — третий, RedSun. Снова LPE в SYSTEM, но через другой механизм Defender, работает на полностью пропатченных системах после апрельского обновления. CVE нет, патча нет.

Репозиторий на GitHub остаётся доступен, несмотря на пометку платформы.

BlueHammer (CVE-2026-33825): закрыто

BlueHammer эксплуатирует механизм ремедиации Defender. Схема такая:

1. Атакующий кладёт файл, который Defender гарантированно задетектит.

2. В момент, когда Defender начинает операцию с файлом, эксплойт ставит на него batch oplock — и операция замирает.

3. Пока Defender «заморожен», атакующий подменяет целевой каталог NTFS junction point, который ведёт в C:\Windows\System32.

4. Oplock отпускается. Defender продолжает операцию, но пишет уже по подменённому пути — со своими SYSTEM-правами.

5. Перезаписанный системный бинарь запускается штатно и даёт SYSTEM-шелл.

Патчить — апрельское кумулятивное обновление. Если оно накатано, конкретно BlueHammer у вас закрыт. Но это один вектор из трёх.

RedSun: то же, но через облачные метки, и без патча

RedSun бьёт в другую часть Defender — в обработку файлов с атрибутами Cloud Files (тот самый механизм, через который работают OneDrive-плейсхолдеры). Когда Defender видит вредоносный файл с cloud-тегом, он не удаляет его, а пытается восстановить в исходное место. Логика понятная: файл помечен как облачный, значит его «настоящая» копия в облаке, а локальная — просто placeholder, который нужно переписать.

Именно на этом шаге проверки пути нет. Вообще.

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

1. Через Windows Cloud Files API (cldapi.dll) в файловой системе создаётся файл с cloud-меткой и EICAR-строкой внутри. EICAR нужен, чтобы гарантированно спровоцировать Defender.

2. Defender детектит, запускает восстановление из облака.

3. Batch oplock тормозит операцию в нужный момент.

4. NTFS junction перенаправляет целевой каталог в C:\Windows\System32.

5. Defender продолжает запись и переписывает TieringEngineService.exe атакующим бинарём. С SYSTEM-правами, под собственным процессом.

6. Дальше подменённый сервис запускается через COM-объект Storage Tiers Management — тоже от SYSTEM.

По описаниям исследователей, надёжность близка к 100% на Windows 10, Windows 11 и Windows Server 2019+, если на машине есть cldapi.dll (он есть практически везде) и включён Defender с real-time protection.

Дефект при этом тривиальный. В цепочке функций от детекта до записи нет ни одного вызова DeviceIoControl(FSCTL_GET_REPARSE_POINT) или GetFinalPathNameByHandle. То есть путь, по которому Defender будет писать, не проверяется на reparse point даже формально. Один вызов — и уязвимости бы не было.

UnDefend: Defender перестаёт обновляться и при этом рапортует, что всё ок

UnDefend не повышает привилегии. Он занимается тем, что ослепляет сам Defender, и в этом его ценность для атакующего.

Два режима:

• Пассивный. Блокирует механизм обновления сигнатур. Defender продолжает работать, но его база замораживается на текущем состоянии. Всё, что Microsoft напушит потом, — мимо. Для EDR-консоли эндпоинт при этом выглядит здоровым.

• Агрессивный. Пытается полностью отключить Defender. Но срабатывает только когда Microsoft катит major platform update, который заменяет MsMpEng.exe и соседние бинари. В обычном режиме агрессивный режим не ломает Defender насквозь — просто ждёт апдейта и использует его как триггер.

В живых атаках Huntress видел запуск UnDefend.exe как child-процесса cmd.exe под Explorer с флагом -agressive — именно в такой комбинации.

Патча нет. CVE нет.

Почему это читается как цепочка, а не три отдельных бага

Три эксплойта от одного автора, выпущенные за две с половиной недели, покрывают ровно ту пару шагов, которая нужна для типичной пост-эксплуатационной активности:

Сценарий, который Huntress реконструировал по одному из инцидентов: злоумышленники зашли через угнанные креды SSL-VPN, положили RedSun.exe и UnDefend.exe в пользовательские папки Downloads и Pictures (иногда переименованные в FunnyApp.exe или z.exe), запустили разведку (whoami, cmdkey, перечисление AD), подняли привилегии через RedSun, вырубили обновления Defender через UnDefend. Дальше — что угодно: дампить LSASS, сносить теневые копии, раскатываться по домену.

Отдельная ирония в том, что в обоих LPE-эксплойтах атакующий не обходит Defender. Он его использует как привилегированного записывальщика в System32.

Что делать сейчас

Это не список «рекомендаций», это минимум.

1. Накатить апрельский Patch Tuesday на все Windows. BlueHammer закрывается только этим.

2. Проверить версию платформы Defender и убедиться, что обновления сигнатур действительно приходят. UnDefend ломает именно этот канал, и консоль при этом показывает зелёный статус. Нужна внешняя телеметрия: приходят ли определения на эндпоинт, совпадает ли дата последнего апдейта с ожидаемой.

3. Зафиксировать SHA-256 C:\Windows\System32\TieringEngineService.exe и завести алерт на любое его изменение. Это прямая цель RedSun — если хеш поменялся, это индикатор компрометации, а не плановое обновление.

4. Мониторить появление бинарей RedSun.exe, UnDefend.exe, FunnyApp.exe (и рандомно переименованных коротких имён вроде z.exe) в пользовательских Downloads, Pictures и двухбуквенных подпапках.

5. Алерт на UnDefend.exe как child-процесс cmd.exe под Explorer, особенно с флагом -agressive. Это не нормальная активность ни для одного легитимного сценария.

6. Относиться к компрометации SSL-VPN как к инциденту высокой критичности. До апреля это означало «возможный initial access»; сейчас это означает, что у атакующего под рукой готовый путь до SYSTEM на любой Windows в сети.

7. Не полагаться только на EDR поверх Defender. Если вектор детекта целиком завязан на Defender и его телеметрию, и сам Defender — цель эксплойта, у вас одна точка отказа. Сетевые и identity-сигналы в этот период — вторая линия.

Когда появится out-of-band патч для RedSun и UnDefend — сейчас неизвестно. Следующий плановый Patch Tuesday — май, то есть окно уязвимости минимум несколько недель.

Источники

• Huntress Labs: разбор активных атак с BlueHammer/RedSun/UnDefend

• CloudSEK: технический разбор RedSun и цепочки функций Defender

• Help Net Security, The Hacker News: хронология публикаций и реакции MSRC

• heise online: сводка по трём уязвимостям

• GitHub-репозиторий Nightmare-Eclipse (доступен на момент публикации)