Microsoft Defender zero-day CVE-2026-41091: путь к SYSTEM

CISA добавила CVE-2026-41091 в каталог Known Exploited Vulnerabilities 20 мая 2026 года - дедлайн 3 июня, две недели на патч для федеральных агентств. EPSS 0.0820 при перцентиле 0.9458 - верхние 6% по вероятности эксплуатации за 30 дней. На GitHub уже лежит публичный PoC (tc4dy/CVE-2026-41091-PoC-Exploit) под именем RedSun: цепочка от непривилегированного пользователя до NT AUTHORITY\SYSTEM через Cloud Files API и NTFS junction.

Суть до смешного проста: Microsoft Malware Protection Engine, работающий от SYSTEM, не проверяет, куда реально ведёт путь к файлу, прежде чем выполнить привилегированную операцию. Классический link following (CWE-59). Антивирус сам превращается в инструмент повышения привилегий - иронию оцените сами.


CVSS-вектор по полочкам. AV:L - эксплуатация требует локального доступа, удалённо не прилетит. PR:L - хватит обычного доменного пользователя без админских прав. UI:N - жертве ничего нажимать не надо. C:H/I:H/A:H - полная компрометация хоста: конфиденциальность, целостность, доступность.

Предусловия:


Зачем это атакующему? После initial access - фишинг, скомпрометированный VPN, украденные credentials - у оператора есть сессия от DOMAIN\lowuser. Для дампа LSASS, отключения EDR, установки persistent-импланта или lateral movement нужен SYSTEM. Вот тут-то Defender и становится лестницей наверх.

Link following атака Windows: анатомия CWE-59​

CWE-59 - программа обращается к файлу по имени, но не проверяет, что это имя - ссылка на совершенно другой ресурс. По данным MITRE CWE, вероятность эксплуатации - Medium, последствия бьют по конфиденциальности (Read Files or Directories), целостности (Modify Files or Directories) и позволяют выполнение неавторизованного кода. Платформы: Windows, Unix, любой язык. CWE-59 - потомок CWE-706 (Use of Incorrectly-Resolved Name or Reference).

На практике это не абстракция из спецификации - это конкретные примитивы NTFS, каждый со своими правами и ограничениями.

Примитивы ссылок NTFS​

NTFS Junction (directory junction) - reparse point типа IO_REPARSE_TAG_MOUNT_POINT, перенаправляющий обращение к каталогу на другой каталог. Создаётся через mklink /J link target или программно через DeviceIoControl с FSCTL_SET_REPARSE_POINT. И вот что важно: привилегия SeCreateSymbolicLinkPrivilege не нужна - хватит права записи в родительский каталог. Любой пользователь с доступом к %TEMP% может создать junction, указывающий на C:\Windows\System32. Именно это свойство делает junction основным оружием в link following атаках.

Символические ссылки - reparse point IO_REPARSE_TAG_SYMLINK, могут указывать на файлы и каталоги. В стандартной enterprise-конфигурации Windows создание требует SeCreateSymbolicLinkPrivilege или Developer Mode (Windows 10 1703+). В корпоративных средах обычно недоступны без привилегий - поэтому junction и остаётся рабочей лошадкой.

Hard links - альтернативные имена файла на одном NTFS-томе. Непривилегированный пользователь создаёт hard link через CreateHardLink API на файл с доступом на чтение. Работают только для файлов, не каталогов.

Object Manager symlinks - ссылки в пространстве имён ядра (\??\, \GLOBAL??\). WinObjEx64 позволяет визуально исследовать эти объекты, но создание требует специфических привилегий. В некоторых цепочках эксплуатации комбинируются с mount points для переадресации на уровне устройств.

Когда привилегированный процесс (SYSTEM) вызывает CreateFile по пути в пользовательском каталоге, а каталог - junction на C:\Windows\System32, ядро послушно следует за reparse point. Process Monitor покажет финальный путь в столбце Detail, а вызывающий процесс даже не узнает о подмене - ядро всё разрешает прозрачно, на уровне файловой системы.

TOCTOU уязвимость и контроль тайминга​

TOCTOU (Time of Check to Time of Use) - разрыв между моментом проверки свойств файла и выполнением операции. В классических link following атаках это окно бывает настолько узким, что эксплойт превращается в лотерею - без детерминированного триггера надёжность стремится к нулю.

Судя по описанию публичного PoC RedSun, техника предположительно использует Cloud Files API (cfapi.h) - механизм для облачных sync-провайдеров вроде OneDrive. Предполагаемый механизм (требует верификации по исходному коду PoC): атакующий регистрирует каталог как sync root и получает callback при обращении к файлу. Вместо попытки «попасть в окно» race condition эксплойт получает детерминированное уведомление - момент, когда Defender тянется к файлу. Тут-то каталог и заменяется на junction. Красивый трюк: из гонки со временем делается управляемая операция.

Эксплуатация уязвимости Defender через NTFS junction​

Типовая цепочка после получения SYSTEM:

1. Initial Access - фишинг, скомпрометированные credentials, злоупотребление RMM
2. Execution - запуск эксплойта из пользовательского контекста (admin не нужен)
3. Privilege Escalation - junction + Cloud Files API → SYSTEM (T1068)
4. Defense Evasion - отключение Defender с правами SYSTEM (T1562.001), удаление журналов (T1070.004)
5. Credential Access - дамп LSASS, извлечение Kerberos-тикетов
6. Lateral Movement - pass-the-hash / pass-the-ticket по сети

Уязвимость повышения привилегий Defender - pivot point всей цепочки: без неё оператор застрял бы на low-priv, с ней - полный контроль над хостом и развитие атаки на инфраструктуру.

Маппинг на MITRE ATT&CK​

Обнаружение link following атак​

Детектирование CVE-2026-41091 строится на трёх уровнях: файловая система, процессная активность и корреляция событий Defender.

Индикаторы компрометации CVE-2026-41091​

Согласно анализу SentinelOne, ключевые IoC для обнаружения link following атак на Windows:

Файловая активность. Создание junction points или symlinks в каталогах, сканируемых Defender - пользовательские temp-директории (%TEMP%, %LOCALAPPDATA%\Temp), каталоги загрузок. MsMpEng.exe выполняет запись или удаление файлов вне ProgramData\Microsoft\Windows Defender - обращение к System32, SysWOW64, каталогам сервисов - это аномалия, и серьёзная. Модификация SYSTEM-файлов (DLL сервисов, scheduled tasks) непосредственно после события сканирования Defender - красный флаг.

Процессная активность. Регистрация Cloud Files sync root через CfRegisterSyncRoot из процесса, не являющегося OneDrive, SharePoint или другим легитимным sync-провайдером. Операция редкая, хороший индикатор - если в вашей среде не пишут облачный sync-клиент, такой вызов должен немедленно поднимать алерт. Появление новых сервисов, DLL или scheduled tasks в привилегированных расположениях, коррелирующее с активностью непривилегированных учёток.

Стратегия детекции: аудит доступа к объектам файловой системы (Event ID 4663) на системных каталогах с фильтрацией по операциям с reparse points. Корреляция: событие сканирования Defender → модификация файла от SYSTEM в системном каталоге → исходный путь вёл через пользовательский каталог. Создайте baseline для MsMpEng.exe: нормальные пути записи - ProgramData\Microsoft\Windows Defender и ProgramData\Microsoft\Windows Defender Advanced Threat Protection. Любое отклонение - повод для расследования.

Tamper protection и пересылка операционных логов в SIEM - обязательная мера, тут без вариантов. По рекомендации SentinelOne, также стоит отслеживать установку неожиданных сервисов, драйверов и autoruns сразу после файловых операций Defender.

Быстрая проверка на конкретном хосте:

Патч CVE-2026-41091 и Windows zero-day 2026: три уязвимости одного релиза​

Фиксированные версии: Engine 1.1.26040.8 (CVE-2026-41091 + CVE-2026-45584) и Platform 4.18.26040.7 (CVE-2026-45498). Каналы доставки: Windows Update, WSUS, Microsoft Configuration Manager, UNC file share.

«Defender обновляется автоматически» - допущение, которое стабильно ломается в enterprise. Я за последний год видел все эти сценарии, и по данным Penligent, типичные точки отказа:

• Серверы в DMZ и air-gapped сети - автоматическое обновление отключено или идёт через WSUS без одобренного пакета
• Defender в passive mode - на хостах со сторонним AV engine загружен, но обновление может не происходить по штатному расписанию, а уязвимость никуда не делась
• Stale golden images - VDI-шаблоны, не обновлённые после 19 мая, разворачиваются с уязвимой версией при каждом новом инстансе. Каждый раз. Снова и снова
• Intune update rings - задержки между кольцами оставляют production-хосты без патча неделями

Массовая верификация через PowerShell Remoting:
Результат со столбцом Vuln = True - хост требует немедленного патчинга. По рекомендации RedLegg, приоритизировать хосты с untrusted local execution paths: shared-среды, developer-воркстейшены, multi-user системы.

Три CVE одного релиза:


CVE-2026-45498 заслуживает отдельного внимания: EPSS 0.6308 - перцентиль 0.9916, top 1% по вероятности эксплуатации. DoS-уязвимость в Microsoft Defender Antimalware Platform (CWE-400), способная вывести Defender из строя. CISA SSVC: Attend (exploitation: active, technical impact: partial).

CVE-2026-45584 - heap-based buffer overflow (CWE-122) с вектором AV:N/AC:H/PR:N/UI:N - сетевая RCE без аутентификации, но с высокой сложностью эксплуатации. CISA SSVC: Track (мониторить). MSRC severity - Critical (RCE без аутентификации); MSRC использует собственную шкалу (Critical/Important/Moderate/Low), не привязанную к CVSS-диапазонам NVD, поэтому CVSS 8.1 HIGH и MSRC Critical не противоречат друг другу.

Каждый антивирусный продукт, работающий от SYSTEM и выполняющий файловые операции по путям, которые может контролировать непривилегированный пользователь, - потенциальная мишень для link following. CVE-2026-41091 не аномалия, а подтверждение паттерна: security products are attack surface. За последние два года я видел аналогичные цепочки с junction-подменой в разных endpoint protection решениях. Разница в том, что Microsoft Defender стоит на сотнях миллионов машин «из коробки» - масштаб поражения несопоставим.

Устойчивая проблема - blue team фокусируется на мониторинге пользовательских процессов и сетевого трафика, а файловые операции привилегированных сервисов (MsMpEng.exe, backup-агенты, system updaters) живут в слепой зоне. MsMpEng.exe удаляет файл в System32 - и все спокойно кивают: «ну это же Defender, ему можно». Пока кто-то не посмотрит, откуда пришёл исходный путь.

Создание baseline файловых операций security-продуктов и алертинг на аномалии - задача, которую многие SOC-команды решают только после инцидента. Те, кто сделает это до следующего zero-day в protection engine, выиграют не только против CVE-2026-41091, а против целого класса уязвимостей повышения привилегий через symlink.

Формула на бумаге понятна - junction создать, callback получить, путь подменить. Но стабильное воспроизведение TOCTOU-цепочки по-настоящему ощущается только на живом стенде, где видишь тайминги в Process Monitor и трассируешь вызовы MsMpEng.exe в реальном времени. Детали механизма Cloud Files callback здесь - реконструкция по краткому описанию PoC; для верификации конкретных примитивов смотрите исходный код: github.com/tc4dy/CVE-2026-41091-PoC-Exploit. Если хотите отработать подобную цепочку руками - на HackerLab есть лабы с privilege escalation через symlink-примитивы Windows.