На проверке CVE-2026-69836: разбор критической уязвимости десериализации в Microsoft Entra ID

За последний год я трижды эксплуатировал insecure deserialization в .NET-сервисах на пентестах - дважды BinaryFormatter в legacy WCF, один раз кастомный TypeNameHandling.All в JSON.NET API. Каждый раз цепочка заканчивалась RCE через ysoserial.net. Когда 20 августа 2026 года Microsoft опубликовала CVE-2026-69836 с CVSS 10.0 и пометкой CWE-502 в Entra ID - облачном identity provider, через который проходит аутентификация для Microsoft 365, Azure и тысяч корпоративных приложений - я отложил всё остальное. Это не рядовой RCE в веб-приложении. Это дыра в trust root, на котором держится вся облачная инфраструктура мелкософта.

Три факта из верифицированных данных:

• Уязвимый компонент - серверная часть Microsoft Entra ID (облачный сервис, ранее Azure Active Directory)
• Вектор - неаутентифицированный атакующий достигает десериализатора через сеть
• Результат - удалённое выполнение кода (Remote Code Execution)

Кто нашёл уязвимость - в advisory не раскрыто. Патч применён server-side, от клиентов действий не требуется.

Статус эксплуатации. CISA в enrichment-данных NVD зафиксировала exploitation: none, решение SSVC - Track (мониторить), не Act (патчить немедленно). Ряд ранних публикаций мог содержать некорректные указания на активную эксплуатацию - если ваша команда дёрнулась на такие сообщения, пересмотрите scope.

EPSS (вероятность эксплуатации в 30 дней): 0.0155, перцентиль 73.40%. Для CVSS 10.0 - умеренно. Логично: уязвимость в cloud-hosted сервисе, уже пропатчена, публичного PoC нет. Для сравнения: CVE-2026-68820 (use-after-free в Windows AFD, CVSS 7.0, подтверждённая эксплуатация в дикой природе) имеет EPSS 0.0618 и перцентиль 92.98%. Запомните эту пару - она ещё всплывёт в конце.

CVSS-вектор 10.0 - покомпонентный разбор CVSS 10.0 уязвимости​

Вектор: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H

Числовой score - формальность. Ценность в разборе компонентов.

AV:N (Attack Vector: Network) - уязвимый компонент доступен через сеть. Для identity-сервиса с глобальными endpoint'ами это достижимость из любой точки интернета. Без VPN, без VDI, без компрометации периметра.

AC:L (Attack Complexity: Low) - не нужны race conditions, зависимости от конфигурации жертвы или специфические условия окружения. Нюанс: AC:L описывает сложность условий атаки, а не сложность разработки эксплойта. Собрать рабочий gadget chain для CWE-502 - нетривиальная инженерная задача, но CVSS этот аспект не оценивает.

PR:N (Privileges Required: None) - атакующему не нужен аккаунт в Entra ID. Это принципиально отличает CVE-2026-69836 от большинства cloud identity-уязвимостей, где требуется хотя бы гостевой доступ в тенанте или скомпрометированный service principal.

UI:N (User Interaction: None) - без фишинга, без consent-запросов, без кликов жертвы.

S:C (Scope: Changed) - самый жирный компонент для identity-инфраструктуры. Changed scope по CVSS 3.1: эксплуатация уязвимого компонента бьёт по ресурсам, которые управляются другим security authority. Для Entra ID это критично - identity provider контролирует авторизацию для downstream-сервисов: Microsoft 365, Azure subscriptions, тысячи третьесторонних приложений через SAML/OIDC federation. Конкретную архитектуру, обусловившую S:C, Microsoft не раскрыла, но сам факт такой оценки от вендора говорит о потенциальном пересечении tenant-границ.

C:H / I:H / A:H - максимальный импакт по конфиденциальности, целостности и доступности.

Сумма: неаутентифицированный сетевой RCE с низкой сложностью, пересечением границ безопасности и максимальным импактом. При таком векторе 10.0 - единственный математически возможный score.

Десериализация CWE-502 в контексте облачной идентификации​

CWE-502 (Deserialization of Untrusted Data) - класс уязвимостей, где приложение восстанавливает объекты из сериализованных данных без валидации типа или структуры. Последствия по MITRE CWE: Modify Application Data (Integrity), DoS через Resource Consumption (Availability) и Varies by Context (Other).

Как десериализация превращается в Microsoft Entra RCE​

Концептуальная модель эксплуатации CWE-502:

Untrusted input → Deserializer → Object instantiation → Gadget chain → Code execution

Gadget chain - последовательность классов в runtime, где конструктор или метод одного объекта триггерит побочный эффект другого, и в итоге - выполнение произвольного кода. В .NET (на котором исторически построен Azure AD / Entra ID) опасные десериализаторы - BinaryFormatter, SoapFormatter, ObjectStateFormatter и JSON.NET с TypeNameHandling != None.

Безопасная архитектура вместо прямой десериализации использует цепочку: parse into inert data → schema validation → strict type allowlist → construct safe application object. Выпадение любого звена - и получаем CWE-502.

Что конкретно ломали? Microsoft не раскрыла ни десериализатор, ни формат объекта, ни API-endpoint, ни gadget chain в CVE-2026-69836. Публичного PoC нет - по данным мониторинга, все candidate-репозитории на GitHub отфильтрованы как fakes или README-only. Конкурентный анализ (Penligent) подтверждает: «diagrams or articles claiming that CVE-2026-69836 works through a specific HTTP endpoint, JSON property, .NET BinaryFormatter object should be treated skeptically unless Microsoft or a credible researcher publishes evidence». Всё описанное выше - контекст CWE-502 в .NET-среде, не реконструкция конкретного эксплойта.

Что CWE-502 сообщает о blast radius​

Категория «Varies by Context» из описания CWE-502 - тут ключевая. Для изолированного веб-приложения CWE-502 обычно означает shell на одном сервере. Для identity provider контекст радикально другой: потенциальный доступ к signing keys, tenant metadata, authentication flows всех downstream-сервисов.

Примечательный факт: в официальном списке платформ CWE-502 указаны Java, Ruby, PHP, Python, JavaScript - .NET не упомянут. Хотя на практике это одна из самых насыщенных gadget-цепочками сред с десятками payload'ов в ysoserial.net. Забавное упущение.

Почему удалённое выполнение кода в Entra ID - не обычный web RCE​

На пентестах RCE в изолированном веб-приложении - один скомпрометированный хост, lateral movement через сетевые сегменты, постепенная эскалация. RCE в identity provider - принципиально другая категория.

Entra ID - trust root. Каждый сервис, использующий Entra для аутентификации, безусловно доверяет токенам, подписанным ключами Entra. Вот разница в двух сценариях:

Параметр	RCE в веб-приложении	RCE в identity provider
Начальный доступ	Один хост/контейнер	Signing infrastructure
Blast radius	Сетевой сегмент	Все downstream-тенанты
Persistence	Webshell, cron, systemd	Token forgery, federation manipulation
Detection	EDR, сетевой мониторинг	Только audit logs identity plane
MFA bypass	Не применимо	Потенциально полный (токены генерируются в обход auth flow)
Lateral movement	Сетевой	Через identity plane - невидим для network-based detection

Аналогия из недавней истории: атака Golden SAML (2020-2021), где компрометация on-prem ADFS-сервера позволяла подписывать SAML-assertion для облачных сервисов. CVE-2026-69836 потенциально даёт тот же примитив, но уже на уровне cloud-hosted identity provider - то есть без необходимости ломать on-prem инфраструктуру.

Потенциальные цепочки эксплуатации CVE-2026-69836 через MITRE ATT&CK​

📚 Часть контента скрыта. Этот материал доступен участникам сообщества с рангом One Level или выше
Получить доступ просто — достаточно зарегистрироваться и проявить активность на форуме

Зарегистрироваться или Войти

Lateral Movement:

• Web Session Cookie (T1550.004) - использование подделанных session tokens для доступа к downstream-сервисам. При компрометации identity provider каждый downstream-сервис потенциально открыт

Ключевой момент: все эти техники работают на уровне identity plane, не на уровне сети. Network-based IDS/IPS, EDR на endpoint'ах, сегментация - ничего из стандартного защитного стека эту активность не видит.

Assume-breach: что проверять в логах Entra ID​

Microsoft заявила, что уязвимость Azure AD десериализация пропатчена server-side. Формально верно. На практике для критичных тенантов стоит превентивно проверить логи за 30-дневное окно до патча - даже при подтверждённом отсутствии эксплуатации. Паранойя? Может быть. Но я предпочитаю потратить час на KQL, чем потом объяснять руководству, почему не проверил.

Привилегированные роли​

Назначения Global Administrator, Privileged Role Administrator, Application Administrator за подозрительный период:

AuditLogs
| where TimeGenerated > ago(30d)
| where OperationName has "Add member to role"
| where tostring(TargetResources[0].modifiedProperties[0].newValue)
    has_any ("Global Administrator", "Privileged Role Administrator")
| project TimeGenerated, InitiatedBy, TargetResources

Service Principals и App Credentials​

Новые service principals или добавление secrets/certificates к существующим - стандартный persistence после компрометации identity plane:

AuditLogs
| where TimeGenerated > ago(30d)
| where OperationName in (
    "Add service principal credentials",
    "Add application",
    "Add service principal"
)
| project TimeGenerated, InitiatedBy, TargetResources, AdditionalDetails

Admin Consent Grants​

Через скомпрометированный backend атакующий мог одобрить permissions для подконтрольного приложения:

AuditLogs
| where TimeGenerated > ago(30d)
| where OperationName has "Consent to application"
| where Result == "success"
| project TimeGenerated, InitiatedBy, TargetResources

Ограничение, о котором не пишут в advisory: sign-in логи тут малополезны. Если эксплуатация происходит на серверной стороне Entra, она может не генерировать стандартные sign-in events - атакующий оперирует ниже уровня, на котором записываются пользовательские аутентификации.

Что делать security-команде после патча Microsoft Entra ID​

Если SIEM с логами Entra не настроен​

Это первоочередная задача - всё остальное подождёт. Включите streaming Entra audit logs и sign-in logs в SIEM. Без этого у вас нет видимости в identity plane, и любой следующий CVE в Entra оставит вас слепыми. Включите Continuous Access Evaluation (CAE) - это сокращает lifetime токенов и уменьшает окно эксплуатации. Проведите ревизию Privileged Identity Management (PIM): все standing assignments Global Admin и Privileged Role Admin замените на eligible с MFA-активацией.

Если SIEM настроен​

Прогоните KQL-запросы из предыдущего раздела. Проверьте workload identities - managed identities и service principals с высокими permissions. Валидируйте, что все федерации (SAML, OIDC) используют ожидаемые signing certificates.

Частые вопросы от команд​

MFA защитит? Нет. MFA работает на уровне user authentication flow. Если RCE на серверной стороне позволяет генерировать токены в обход этого flow - MFA просто не участвует.

Conditional Access предотвратит эксплуатацию? Нет. Conditional Access enforcement происходит на стороне Entra. Если сам Entra скомпрометирован - enforcement-точка тоже скомпрометирована. Замок не поможет, если сломали дверную коробку.

Сканеры обнаружат CVE-2026-69836? Нет. Nessus, Qualys, Nuclei работают с клиентской инфраструктурой. Серверные компоненты Entra для сканирования недоступны - это hosted service.

Облачные CVE меняют модель vulnerability management​

CVE-2026-69836 - пример категории, где стандартный цикл «обнаружение → приоритизация → патч → валидация» разваливается. Клиент не может установить патч, не может просканировать уязвимый компонент, не может верифицировать remediation. Microsoft патчит server-side и публикует CVE «для прозрачности».

Для vulnerability management это означает: облачные CVE с CWE-502 в identity-инфраструктуре должны автоматически триггерить assume-breach процедуру. Не patch-management workflow, не «добавить в backlog», не «ждать next scan cycle» - а конкретный набор проверок audit logs, ревизию привилегированных ролей и валидацию federation trust.

По данным CISA, атрибут Automatable: yes для CVE-2026-69836 подтверждает: при наличии рабочего эксплойта автоматизация атаки не требует ручного взаимодействия с каждой жертвой. Scale потенциальной атаки - принципиально другой. (Прямое сравнение с локальными EoP-уязвимостями, где Automatable: no, некорректно - SSVC-атрибут оценивает возможность автоматизации именно сетевого вектора.)

Я наблюдаю, как индустрия постепенно осознаёт разницу между «CVE пропатчена - вопрос закрыт» и «CVE пропатчена - а что было между появлением уязвимости и патчем?». Для on-prem софта этот вопрос решается через patch gap analysis и forensic triage. Для cloud-hosted identity provider у клиента нет инструментов forensic на уровне серверной инфраструктуры - остаются только audit logs на уровне тенанта. Это не дефект процесса, это архитектурная реальность shared responsibility model. Но она требует от security-команд другого подхода: не «мы закрыли уязвимость», а «мы проверили, что через наш тенант не прошли последствия чужой уязвимости».

Ещё один момент, который редко проговаривают вслух. «No customer action required» в advisory Microsoft - юридически корректно, но операционно недостаточно. CISA SSVC для CVE-2026-69836 - Track, не Act. Для CVE-2026-68820 (use-after-free в Windows AFD, CVSS 7.0, подтверждённая эксплуатация, CISA KEV) - решение Act. Уязвимость с CVSS 7.0 получает более высокий приоритет реагирования, чем уязвимость с CVSS 10.0 - потому что SSVC учитывает реальную эксплуатацию, а CVSS - только технический потенциал. Если ваша программа vulnerability management до сих пор приоритизирует исключительно по CVSS score - CVE-2026-69836 хорошая иллюстрация того, почему этого недостаточно. На HackerLab есть лаба, где .NET-десериализацию нужно раскрутить в полную цепочку самостоятельно - от crafted payload до RCE без подсказок, и именно там разница между «знаю теорию CWE-502» и «могу собрать gadget chain» становится очевидной.