ShieldBreak в Microsoft Defender: что подтверждено, какой патч обходит уязвимость и что делать администраторам

ShieldBreak — публично раскрытая уязвимость повышения привилегий в Microsoft Malware Protection Engine, движке, который используется антивирусом Microsoft Defender. Ей присвоен идентификатор CVE-2026-69414 и оценка High с показателем CVSS 7.8. Уязвимость описывают как обход исправления Microsoft для связанной проблемы RoguePlanet (CVE-2026-50656), устраненной в июле. По состоянию на 19 августа Microsoft признала проблему и сообщила, что готовит обновление, однако отдельный патч в предоставленных источниках не указан.

Риск серьезный, но имеет важное ограничение: злоумышленнику обычно сначала нужны локальный доступ, учетная запись с аутентификацией или возможность выполнить код на устройстве. ShieldBreak — это прежде всего инструмент развития уже состоявшейся компрометации, а не самостоятельный удаленный захват компьютера.

Что именно меняет ShieldBreak после RoguePlanet

RoguePlanet была другой уязвимостью повышения привилегий в Defender. Она была связана с некорректным разрешением ссылок перед доступом к файлу и классифицировалась как CWE-59. В июле Microsoft выпустила исправление; в качестве исправленной базовой версии Malware Protection Engine указывалась 1.1.26060.3008.

ShieldBreak важна потому, что опубликованные материалы описывают иной путь эксплуатации, который, предположительно, обходит исправление RoguePlanet, а не просто повторяет исходную атаку. Результат при этом похож: локальный пользователь с низкими привилегиями может получить контекст

NT AUTHORITY\SYSTEM

Для администраторов это означает следующее: наличие июльского обновления RoguePlanet само по себе не доказывает, что отдельная проблема ShieldBreak закрыта. Публичный PoC был опубликован 12 августа, а запись Microsoft о CVE указывает, что работа над обновлением безопасности продолжалась.

Какие версии Windows, по имеющимся данным, затронуты

Наиболее конкретные публичные заявления относятся к следующим средам:

• Windows 11 25H2;
• сборки Windows 11 Canary и других каналов Insider;
• Windows Server 2025.

Исследователь, опубликовавший PoC, заявил о 100% успешности на этих тестовых средах. Независимые публикации также сообщали о воспроизведении на полностью обновленной системе Windows 11. Однако эти данные не являются подтвержденной Microsoft матрицей совместимости и не означают универсальную успешность на всех сборках.

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

Публичное описание CVE от Microsoft подтверждает затронутую область — Malware Protection Engine в Defender, — но в предоставленных материалах нет полного списка уязвимых версий и номеров сборок.

Использовалась ли уязвимость в атаках

В предоставленных источниках нет свидетельств того, что ShieldBreak применялась в реальных атаках. Публичный PoC повышает вероятность того, что технику будут изучать как защитники, так и злоумышленники, но без телеметрии, отчета реагирования на инцидент или официального сообщения разведки угроз говорить об эксплуатации «в дикой природе» нельзя.

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

Что произошло со сканированием Defender

Параллельно сообщалось об отдельной операционной проблеме после недавних обновлений движка Defender и базы сведений о безопасности. Пользователи описывали сбои быстрых и полных проверок почти в самом конце, зависание Offline Scan на 91%, а также падения MsMpEng.exe, связанные с mpengine.dll. В некоторых сообщениях фигурировала строка ошибки 0x000005.

Чаще всего упоминались следующие версии движка:

• 1.1.26070.7;
• 1.1.26080.2.

В записи о сбое на Microsoft Q&A были указаны версия платформы Defender 4.18.26070.9, версия Malware Protection Engine 1.1.26070.7 и ошибка в mpengine.dll. При этом в записи приведен код исключения c0000005, который отличается от 0x000005, указанного в других публикациях.

В одном из отчетов рядом с этими версиями движка перечислялись обновления Security Intelligence с номерами 1.457.222.0, 1.457.225.0, 1.457.226.0, 1.457.227.0 и 1.457.230.0. Там же утверждалось, что переход на 1.457.236.0 устранил сбои у некоторых пользователей. Однако перед тем как считать эту версию универсальным исправлением, результат следует сверить с актуальной информацией Microsoft.

Вызвало ли исправление ShieldBreak сбои сканирования

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

Поэтому формулировка «Microsoft сломала Defender, пытаясь исправить ShieldBreak» пока остается правдоподобной, но неподтвержденной гипотезой. Оба события стоит отслеживать вместе, поскольку они затрагивают одну общую область движка, но считать их окончательно связанными преждевременно.

Стоит ли откатывать базы Defender

В некоторых сообщениях говорится, что возврат к предыдущим определениям Defender восстанавливал работу сканирования. Это делает откат полезным диагностическим инструментом, но не безопасным универсальным решением. Возврат содержимого базы или движка может удалить новые детектирования, а также промежуточное смягчение, которое Microsoft могла распространить через обновления.

Более осторожная тактика выглядит так:

1. Поддерживать актуальными платформу Defender, движок, сведения о безопасности и обновления Windows, если только контролируемое реагирование на инцидент не требует иного решения.
2. Проверить состояние защиты устройства, версии движка и платформы, а также номер обновления Security Intelligence.
3. Сначала тестировать откат на изолированных системах и заранее документировать компенсирующие меры.
4. Если проверки Defender завершаются сбоем, добавить независимый сканер по требованию или канал сканирования на базе EDR.
5. Как можно скорее вернуть актуальные обновления защиты после появления проверенного совместимого выпуска.

Как снизить риск до выхода патча ShieldBreak

Ограничить локальный доступ

По возможности используйте стандартные учетные записи, удаляйте ненужные права локального администратора, ограничивайте RDP и средства удаленного управления, не применяйте общие административные учетные данные. Контроль разрешенных приложений, ограничения для скриптов и телеметрия конечных точек также уменьшают вероятность того, что злоумышленник сможет перейти от первоначального локального доступа к уязвимому движку.

Не отключать Tamper Protection

Защита от несанкционированного изменения настроек Defender может помешать злоумышленнику ослабить конфигурацию антивируса. Но она не устраняет уязвимый путь в движке и не является патчем ShieldBreak.

Использовать правила Attack Surface Reduction

Правила Attack Surface Reduction (ASR) помогают ограничить распространенные способы запуска кода и первоначального доступа: злоупотребление скриптами, подозрительное создание процессов, кражу учетных данных и запуск дочерних процессов Office. Однако ASR напрямую не устраняет локальное повышение привилегий в движке Defender, если атакующий уже может запустить PoC. Эти правила должны дополнять, а не заменять контроль доступа и обновление.

Следить за повышением привилегий и сбоями движка

Командам безопасности следует отслеживать неожиданные процессы с уровнем SYSTEM, запущенные из контекста пользователя с низкими правами, подозрительные операции со ссылками или точками повторной обработки, необычные сбои служб Defender, а также повторяющиеся падения MsMpEng.exe и mpengine.dll. Ни один из этих признаков сам по себе не доказывает эксплуатацию ShieldBreak, но они помогают определить системы, которым требуется проверка.

Осторожно подключать стороннюю защиту

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

Итог

ShieldBreak следует рассматривать как уязвимость движка Defender высокой степени опасности, эксплуатируемую локально, с публичным PoC и без подтвержденного патча Microsoft в доступных материалах по состоянию на 19 августа 2026 года. Заявленные 100% успешности на Windows 11 25H2, сборках Canary и Windows Server 2025 вызывают обеспокоенность, но остаются заявлением исследователя, несмотря на сообщения о независимом воспроизведении.

Сбои сканирования — отдельная нерешенная операционная проблема. Их совпадение по времени с обновлениями, многочисленные пользовательские сообщения и сигнатуры падений движка требуют расследования, но не доказывают, что именно ответ Microsoft на ShieldBreak стал причиной. Наименее рискованный подход сейчас — поддерживать актуальные обновления защиты, ограничивать локальное выполнение кода и администрирование, контролировать состояние Defender, при необходимости добавить протестированный резервный канал сканирования и оперативно установить исправление CVE-2026-69414 после его проверки.