Защита привилегированного доступа: как уязвимость ShieldCrash обходит патч Defender

ShieldCrash: новая уязвимость обходит патч Windows Defender

10 сентября 2026 года стало известно об эксплойте ShieldCrash: с его помощью можно обойти уже выпущенный патч Microsoft и прочитать произвольные файлы с правами SYSTEM — причём даже на полностью пропатченных Windows 10, Windows 11 и Windows Server. Для компаний, выстраивающих защиту привилегированного доступа, эта история — повод свериться: насколько быстро у них закрываются подобные бреши и кто на самом деле контролирует привилегированные учётные записи после установки очередных обновлений.

PoC-код ShieldCrash выложен в открытом доступе на GitHub — значит, воспроизвести атаку способен практически любой злоумышленник, уже закрепившийся локально на машине жертвы. Автор находки — исследователь, работающий под псевдонимами Nightmare Eclipse, Chaotic Eclipse и MSNightmare; это часть его затяжного противостояния с Microsoft: с апреля 2026 года он раскрыл уже одиннадцать уязвимостей, причём не только у Microsoft, но и в продуктах Kaspersky, CrowdStrike, Avast и NVIDIA.

Как работает атака: цепочка от RoguePlanet до ShieldCrash

ShieldCrash — не разовая находка, а очередной виток истории одного и того же компонента Windows Defender, Microsoft Malware Protection Engine. Летом 2026 года тот же исследователь обнаружил брешь RoguePlanet (CVE-2026-50656), которую Microsoft устранила. В августе всплыла новая проблема — ShieldBreak (CVE-2026-69414, CVSS 7,8): патч для неё вошёл в состав Malware Protection Engine 1.1.26080.3 и вышел на прошлой неделе, а уже сразу после сентябрьского «вторника обновлений» исследователь опубликовал эксплойт ShieldCrash.

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

Какие риски несёт ShieldCrash для доступа с повышенными правами в компании

Опубликованная версия PoC умеет только читать произвольные файлы с правами SYSTEM: записать данные или получить полноценный SYSTEM-шелл через неё пока не получится. Но и одной возможности прочитать любой файл от имени учётной записи, под которой работают системные службы Windows, злоумышленнику уже достаточно, чтобы нанести серьёзный урон. Правами SYSTEM защищены как раз самые чувствительные файлы операционной системы — те, что обычно недоступны рядовым пользователям и учётным записям без специальных прав.

Автор эксплойта сам признаёт, что код поддаётся доработке, — а значит нынешнее ограничение «только чтение» не даёт гарантий на будущее. Для бизнеса вывод такой: злоумышленник, закрепившийся на одной-единственной рабочей станции, получает шанс подняться от рядового пользователя до контроля над учётными данными с повышенными правами, а дальше распространиться по сети горизонтально, наращивая полномочия на соседних узлах. Именно по такому сценарию развивается немало атак шифровальщиков и целевых вторжений, о которых регулярно пишут ИБ-исследователи: повышение привилегий редко становится конечной целью — чаще это лишь промежуточный шаг на пути к краже данных или развёртыванию вымогательского ПО.

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

Что делать: защита привилегированного доступа при отсутствии полного патча

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

• Следить за бюллетенями Microsoft и оперативно устанавливать все последующие обновления Malware Protection Engine: раз патч оказалось возможно обойти, история с ShieldBreak явно ещё не закончена.
• Сократить количество учётных записей с локальными правами администратора, руководствуясь принципом минимально необходимых прав: чем меньше сотрудников способны сделать первый шаг эксплойта, тем ниже общий риск.
• Внедрить PAM-систему для управления доступом с расширенными правами: выдавать такие права не бессрочно, а на ограниченный срок под конкретную задачу и с обязательной записью сессии.
• Контролировать действия администраторов и системных процессов инструментами EDR или SIEM: любая нетипичная попытка чтения защищённых системных файлов должна попадать в поле зрения службы ИБ.
• Включить многофакторную аутентификацию для административных и других учётных записей с расширенными правами: дополнительный барьер обесценивает украденные хеши даже при состоявшейся компрометации.
• Провести внеплановый аудит прав доступа и убедиться, что после увольнений и переводов сотрудников на другие роли избыточные полномочия действительно отозваны.

Кто относится к привилегированным пользователям в компании

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

• Доменные и локальные администраторы: учётные записи с правами Domain Admin в Active Directory, а также с root- и sudo-доступом на Linux-серверах.
• Администраторы баз данных (DBA) — с правами менять схемы, выгружать и удалять данные.
• Администраторы сетевого оборудования — маршрутизаторов, коммутаторов, межсетевых экранов, VPN-шлюзов.
• Сервисные учётные записи, от имени которых работают службы, скрипты автоматизации и интеграции между системами, — нередко с широкими правами и паролем, который меняют крайне редко.
• Администраторы средств защиты информации — SIEM, антивирусных решений, DLP-систем и самих PAM-платформ.
• Администраторы облачных платформ и виртуализации: те, кто работает с панелями управления гипервизорами, облачными аккаунтами и средами контейнеризации.
• Подрядчики и внешние специалисты — ИТ-аутсорсеры и вендоры с временным удалённым доступом для поддержки систем.
• Администраторы резервного копирования и систем аварийного восстановления (DR) — их учётные записи нередко выпадают из обычного контура контроля доступа.

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

PAM, PIM и PUM: разные подходы к управлению доступом с повышенными правами

На практике термин «управление привилегированным доступом» объединяет сразу несколько смежных, но по-разному сфокусированных подходов. Понимание разницы между ними помогает точнее выбрать, что внедрять именно в вашей организации.

На практике эти подходы не исключают друг друга: зрелая система контроля доступа с повышенными правами, как правило, сочетает элементы всех трёх — постоянный контроль сессий (PAM), временное повышение прав под конкретную задачу (PIM) и системную гигиену самих учётных записей (PUM).

Защищённые рабочие места администраторов (PAW) как дополнительный барьер

Даже самая продуманная PAM-система теряет смысл, если администратор выполняет действия с расширенными правами с обычного рабочего компьютера — того же самого, где он проверяет почту и кликает по ссылкам в мессенджерах. Именно так чаще всего происходит первичное заражение: фишинговое письмо или взломанный сайт дают злоумышленнику плацдарм на машине, а дальше в дело вступают инструменты вроде ShieldCrash для повышения привилегий.

Концепция защищённого рабочего места (Privileged Access Workstation, PAW) снимает эту проблему на уровне устройства: для работы с критичными системами и учётками повышенного уровня выделяют отдельную изолированную машину или виртуальное окружение, которое не задействуют для веб-сёрфинга, почты и офисных задач. К критичным серверам подключаются только с PAW — как правило, через промежуточный jump-сервер, а саму PAW-станцию изолируют от остальной корпоративной сети и дополнительно защищают вторым фактором аутентификации.

Такой подход не отменяет необходимости закрывать патчами уязвимости вроде ShieldCrash, зато заметно снижает шанс, что эксплойт вообще доберётся до административной сессии, — ведь подозрительные вложения администратор просто не открывает с той же машины, откуда управляет доменом или базой данных.

Этапы внедрения PAM в организации: пошаговый план

Системную защиту привилегированного доступа невозможно выстроить одним действием — это процесс из нескольких последовательных этапов.

1. Инвентаризация: составить исчерпывающий перечень учётных записей с расширенными правами, включая сервисные аккаунты и доступ подрядчиков, — именно их служба ИБ чаще всего упускает из виду.
2. Классификация по уровню риска: распределить учётные записи по критичности систем, к которым открыт доступ, — домен, финансовые системы, персональные данные, промышленные контуры.
3. Переход к принципу наименьших привилегий: там, где задачу можно решить временным повышением прав, убрать постоянные административные права.
4. Выбор модели управления: определить, что нужно организации в первую очередь, — элементы PAM для контроля сессий, PIM для just-in-time повышения прав или PUM для порядка в жизненном цикле учётных записей.
5. Пилотное внедрение: протестировать выбранный подход на ограниченном контуре — например, только среди администраторов серверов с персональными данными.
6. Настройка MFA и мониторинга сессий: обязательная многофакторная аутентификация для учётных записей с расширенными правами плюс запись действий администраторов на случай будущего расследования инцидентов.
7. Масштабирование на всю инфраструктуру: последовательное подключение оставшихся систем, сетевого оборудования и сервисных аккаунтов.
8. Регулярный аудит и пересмотр прав: периодическая проверка их актуальности и отзыв полномочий, которые не используются или остались после смены роли сотрудника.

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

Требования регуляторов к защите привилегированного доступа

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

• 152-ФЗ «О персональных данных» обязывает операторов ограничивать доступ к персональным данным и контролировать действия допущенных к ним лиц, включая администраторов информационных систем.
• Приказы ФСТЭК России — в частности, №17 (о защите информации в государственных информационных системах) и №21 (о составе мер по защите персональных данных) — закрепляют конкретные меры управления доступом: разграничение прав, идентификацию и аутентификацию пользователей с расширенными полномочиями, регистрацию событий безопасности.
• 187-ФЗ «О безопасности критической информационной инфраструктуры» обязывает субъекты КИИ защищать значимые объекты от несанкционированного доступа, в том числе со стороны лиц с административными правами, и учитывать эти риски при категорировании объектов.
• У организаций, работающих с конфиденциальной информацией и коммерческой тайной, контроль доступа с повышенными правами обычно проверяется в ходе аудитов ИБ и обследований инфраструктуры — на соответствие как внутренним политикам, так и требованиям регуляторов.

Как партнёр СКБ Контур, мы помогаем компаниям не просто устанавливать технические средства защиты, а выстраивать процессы так, чтобы они реально закрывали требования регуляторов, а не существовали отдельно от них.

Частые вопросы

Что такое ShieldCrash и почему это опасно?

ShieldCrash — PoC-эксплойт, опубликованный 10 сентября 2026 года и обходящий патч Microsoft для уязвимости ShieldBreak (CVE-2026-69414) в компоненте Windows Defender. С его помощью можно читать произвольные файлы с правами SYSTEM, в том числе защищённые системные файлы, а это открывает путь к краже учётных данных.

Какие версии Windows затронуты?

Проблема касается полностью обновлённых Windows 10, Windows 11 и Windows Server — то есть систем, где уже установлен сентябрьский патч Microsoft для ShieldBreak.

Вышел ли официальный патч для ShieldCrash?

На момент публикации у Microsoft ещё нет полноценного патча именно от обхода ShieldCrash: компания закрыла только часть условий, приводивших к исходной проблеме ShieldBreak.

Как защититься от атак с повышением привилегий, если патча ещё нет?

Здесь помогает не отдельное обновление, а системная защита привилегированного доступа: минимум админ-учёток, PAM с временной выдачей расширенных прав, мониторинг действий администраторов через EDR или SIEM и обязательная MFA для таких аккаунтов.

Что такое управление привилегированным доступом (PAM) и зачем оно бизнесу?

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

Чем PAM отличается от обычного управления доступом?

Обычное управление доступом определяет права всех сотрудников для повседневной работы, а PAM фокусируется именно на учётных записях с расширенными правами — администраторах, сервисных аккаунтах, подрядчиках, — добавляя дополнительные меры контроля: хранение паролей в защищённом хранилище, запись сессий, выдачу прав на ограниченный срок под задачу.

С чего начать внедрение PAM в организации?

С инвентаризации: составьте полный перечень учётных записей с расширенными правами, включая сервисные аккаунты и доступ подрядчиков, а затем определите, какие из них открывают доступ к самым критичным системам, — с них и стоит начинать пилотный проект.

Нужен ли PAM небольшой компании?

Даже в компании из нескольких десятков сотрудников обычно найдутся учётные записи с расширенными правами: системный администратор, бухгалтер с доступом к учётной системе, подрядчик по ИТ-поддержке. Полноценная PAM-платформа требуется не каждому, но базовые принципы — минимум привилегий, MFA, журналирование действий администраторов — стоит соблюдать независимо от размера бизнеса.

Как защищённые рабочие места администраторов (PAW) связаны с PAM?

PAW дополняет PAM на уровне устройства: PAM определяет, кто и на каком основании получает доступ с повышенными правами, а PAW гарантирует, что этот доступ реализуется с изолированного, минимально уязвимого устройства, не задействованного в повседневных задачах вроде веб-сёрфинга и почты.

Вывод

История ShieldCrash наглядно демонстрирует: даже патч крупного вендора не гарантирует, что проблема закрыта окончательно, а права SYSTEM остаются одной из самых желанных целей для атакующих. Пока официального исправления нет, единственный рабочий путь — не полагаться на один патч, а выстраивать защиту привилегированного доступа как непрерывный процесс: минимум прав, контроль сессий администраторов, мониторинг аномальной активности и MFA на критичных учётных записях.

Как партнёр СКБ Контур, мы в Контур.Эгиде строим решения именно вокруг этой логики: двухфакторная аутентификация при входе в Windows, VPN и другие критичные системы плюс контроль действий пользователей с расширенными правами — чтобы подобные уязвимости не превращались в реальный инцидент ещё до выхода официального патча.