Патча нет - только временная митигация. CISA добавляет CVE в каталог Known Exploited Vulnerabilities 15 мая с дедлайном 29 мая. 14 дней на реагирование. Для SOC-команд, которые привыкли детектировать Exchange-инциденты по серверным IOC - веб-шеллы, аномальные IIS-процессы, подозрительный outbound - начинается сценарий, где привычные playbook'и бесполезны. Атака целиком разыгрывается в браузере жертвы. Не на сервере. В браузере.
Техническая анатомия CVE-2026-42897
Root cause - CWE-79 (Improper Neutralization of Input During Web Page Generation): Exchange Server недостаточно санитизирует содержимое входящих писем при рендеринге в OWA. Атакующий без аутентификации может выполнить spoofing по сети. По OWASP Top 10 2021 уязвимость попадает под A03:2021 (Injection, куда включена категория XSS); в актуальном OWASP Top 10 2025 - под A05:2025 (Injection), а её последствия - несанкционированный доступ к содержимому почтового ящика - укладываются в A01:2021 (Broken Access Control).NVD при обогащении подтверждает CVSS 8.1 (High) с вектором S:U/C:H/I:H - Scope Unchanged, Confidentiality и Integrity Impact остаются High. MSRC использует собственную качественную шкалу и классифицирует уязвимость как Critical (impact: Spoofing), несмотря на CVSS 8.1 (High). Расхождение стандартное - MSRC учитывает бизнес-контекст и ценность целевой инфраструктуры. Проще говоря: Exchange с почтой CFO для Microsoft критичнее, чем абстрактный CVSS-балл.
| Компонент | Значение | Что это значит для атакующего |
|---|---|---|
| AV:N | Network | Эксплуатация через сеть, физический доступ не нужен |
| AC:L | Low | Нет сложных предусловий |
| PR:N | None | Аутентификация атакующего не требуется |
| UI:R | Required | Жертва должна открыть письмо в OWA |
| C:H / I:H | High / High | Доступ к конфиденциальным данным и их модификация |
| A:N | None | Доступность не затрагивается |
EPSS-оценка: 0.0564, percentile 0.9206 - уязвимость в топ-10% по вероятности эксплуатации в ближайшие 30 дней. CISA SSVC Decision: Act (активная эксплуатация, автоматизация невозможна, полный технический импакт).
Затронутые версии Exchange Server
По данным NVD и MSRC, уязвимы on-premises версии:- Exchange Server 2016 CU23
- Exchange Server 2019 CU14
- Exchange Server 2019 CU15
- Exchange Server Subscription Edition RTM
Exchange Online не затронут. Организации без ESU-подписки остаются с временной митигацией как единственной защитой - прямая иллюстрация OWASP A06:2021 (Vulnerable and Outdated Components). Вендор уже перестал полноценно поддерживать инфраструктуру, а она всё ещё стоит в проде.
Что это даёт атакующему на практике: читать переписку, отправлять письма от имени жертвы для BEC-схем, собирать вложения из переписки с юридическим или финансовым отделом, модифицировать правила пересылки. И всё это - из доверенного интерфейса OWA, без единого алерта на сервере.
Цепочка с маппингом MITRE ATT&CK
- Доставка. Атакующий формирует письмо с обфусцированным JavaScript в теле. Доставка стандартным SMTP-потоком. Маппинг: Phishing (T1566, Initial Access).
- Триггер. Жертва открывает письмо в OWA. Exchange рендерит несанитизированный HTML, JavaScript исполняется в контексте аутентифицированной браузерной сессии. Microsoft уточняет: эксплуатация происходит "при определённых условиях взаимодействия" - конкретный rendering path или состояние интерфейса не раскрыты. Маппинг: Exploitation for Client Execution (T1203, Execution).
- Сбор. Скрипт взаимодействует с OWA-сессией: session tokens, содержимое почтового ящика, вложения, списки контактов. Маппинг: Email Collection (T1114, Collection) - подтехника T1114.002 (Remote Email Collection) описана MITRE для Exchange/Office 365, Atomic Red Team тесты доступны только для Office 365.
- Действие. Отправка писем от имени жертвы, создание inbox rules для пересылки. Возможная зачистка следов: Clear Mailbox Data (T1070.008).
Почему стандартный playbook не срабатывает
Вспомним ProxyLogon (CVE-2021-26855, CVSS 9.1, Critical, CWE-918) - SSRF с RCE на сервере Exchange, тоже засветившийся в ransomware-кампаниях и CISA KEV. Там атакующий оставлял веб-шелл (T1505.003), запускал процессы через PowerShell (T1059.001), создавал серверные артефакты. Для ProxyLogon есть публичные PoC (SharpProxyLogon, exprolog на GitHub), Nuclei-шаблоны для сканирования, и за годы накопилась солидная база IOC.CVE-2026-42897 работает иначе:
- Нет вредоносного вложения для детонации в sandbox
- Нет ссылки для блокировки на mail gateway
- Нет веб-шелла на файловой системе сервера
- Нет аномального процесса в IIS worker
- Нет подозрительного outbound с Exchange-хоста
Масштаб проблемы
Контекст масштабнее одного CVE. По данным отчёта Kiteworks, вскоре после раскрытия CVE-2026-42897 на Pwn2Own Berlin были продемонстрированы дополнительные Exchange-баги с RCE от SYSTEM, запустившие 90-дневный disclosure-таймер. Поверхность атаки Exchange Server не сужается - она расширяется.Detection: что искать в логах при Exchange email spoofing атаке
Требования к окружению
- Доступ к IIS-логам Exchange Server (по умолчанию
%SystemDrive%\inetpub\logs\LogFiles\) - Доступ к Exchange HttpProxy-логам (
%ExchangeInstallPath%\Logging\HttpProxy\OwaProxy\) - SIEM с настроенным сбором из указанных источников (Splunk, Elastic, MaxPatrol SIEM)
- PowerShell 5.1+ на Exchange-сервере
IIS-логи: аномалии OWA-сессий
Специфического URL-паттерна для CVE-2026-42897 в публичных источниках нет - Microsoft не раскрыла деталей пейлоада. Detection строится на выявлении аномального поведения после потенциальной эксплуатации:- Множественные POST-запросы к
/owa/endpoints от одной сессии за короткий интервал - особенно к API чтения писем и скачивания вложений - OWA-сессии с IP-адресами, не совпадающими с baseline пользователя
- Резкий рост объёма запросов из OWA-контекста для конкретного mailbox
Код:
# Путь к логам адаптировать под инсталляцию
Select-String -Path "$env:SystemDrive\inetpub\logs\LogFiles\W3SVC1\*.log" ` -Pattern "POST.*/owa/" | ForEach-Object { ($_ -split '\s+')[2] } | Group-Object | Where-Object { $_.Count -gt 20 } | Sort-Object Count -Descending
Почтовый поток: hunting на уровне transport
На mail gateway или через Exchange Transport Rules - алерты на письма с подозрительными HTML-конструкциями в теле: обфусцированный JavaScript (encode/decode,String.fromCharCode), event handlers (onerror, onload, onmouseover), вложенные <script> теги. Тут без магии - обычный pattern matching, но он хотя бы отсечёт самые тупые варианты пейлоада.Сессионные аномалии
После эксплуатации XSS атакующий действует от имени жертвы в рамках легитимной OWA-сессии. Корреляция в SIEM:- Отправка писем в нехарактерное для пользователя время
- Создание или модификация inbox rules через OWA: проверять командой
Get-InboxRule -Mailbox <user> | Where-Object { $[I].ForwardTo -or $[/I].RedirectTo } - Массовое чтение вложений из переписки, к которой пользователь обычно не обращается
- Действия в OWA от пользователя, который обычно работает через десктопный Outlook (а тут вдруг полез в веб-интерфейс - подозрительно)
Экстренная митигация Exchange Server: EEMS и EOMT
Требования к окружению
- Exchange Server не ниже March 2023 CU (для работы EEMS)
- Elevated Exchange Management Shell для EOMT
- Сетевое подключение к Microsoft Office Config Service (для EEMS)
- Для air-gapped сред: EOMT скачивается заранее
Сравнение вариантов митигации
| Параметр | EEMS | EOMT |
|---|---|---|
| Применение | Автоматическое | Ручной запуск скрипта |
| Требует интернет | Да (OCS) | Нет |
| Air-gapped среды | Не подходит | Подходит |
| Скорость | Минуты (автоматически) | 5-10 минут на сервер |
| Митигация ID | M2.1.x | M2.1.x |
| Верификация | Exchange Health Checker | Exchange Health Checker |
Вариант 1: EEMS (рекомендуется)
Exchange Emergency Mitigation Service включён по умолчанию с сентября 2021 года. Если сервис активен и сервер имеет связность с OCS - митигация M2.1.x применяется автоматически. Проверка: запустить Exchange Health Checker (HealthChecker - Microsoft - CSS-Exchange), в HTML-отчёте найти секцию EEMS. Если M2.1.x в статусе "Applied" - сервер защищён. Надпись "Mitigation invalid for this exchange version" в деталях - косметический баг. При статусе Applied митигация работает корректно, по данным Microsoft Exchange Team.Вариант 2: EOMT (для изолированных сред)
Код:
# Один сервер:
.\EOMT.ps1 -CVE "CVE-2026-42897"
# Все серверы, кроме Edge Transport:
Get-ExchangeServer | Where-Object { $_.ServerRole -ne "Edge" } |
.\EOMT.ps1 -CVE "CVE-2026-42897"
Ограничения митигации
Митигация основана на Content Security Policy (CSP) заголовках. Два принципиальных ограничения, и оба неприятные:Internet Explorer и Edge в режиме IE Mode не поддерживают CSP. Для пользователей этих браузеров митигация не защищает. Это blind spot, который SOC обязана учитывать. Да, в 2025 году IE всё ещё встречается в корпоративных средах - и именно там, где Exchange on-prem.
Побочные эффекты:
- Не работает печать календаря в OWA (workaround: Outlook Desktop)
- Inline-изображения могут некорректно отображаться в reading pane (workaround: отправлять как вложения)
- OWA Light перестаёт работать (deprecated, будет отключён окончательно)
- Healthset OWACalendar.Proxy может показывать unhealthy - игнорировать в мониторинге до полноценного патча
- Опубликованные календари могут возвращать ошибку 500
Статус рекомендации по сохранению митигации после установки патча требует сверки с актуальным MSRC advisory на момент чтения.
Чеклист реагирования на Exchange Server 0-day
Готовый список для передачи администратору Exchange:
📚 Часть контента скрыта. Этот материал доступен участникам сообщества с рангом One Level или выше
Получить доступ просто — достаточно зарегистрироваться и проявить активность на форуме
Получить доступ просто — достаточно зарегистрироваться и проявить активность на форуме
Пятилетняя серия Exchange-уязвимостей - от ProxyLogon до CVE-2026-42897 - обнажила проблему, о которой SOC-команды предпочитают молчать: on-premises Exchange стал самой атакуемой точкой входа в корпоративную инфраструктуру. Каждый новый CVE повторяет один и тот же цикл - раскрытие, экстренная митигация, частичный патч, длинный хвост экспозиции. CVE-2026-42897 добавила к этому циклу новый элемент: атаку без серверных IOC вообще. Привычный playbook "ищем веб-шеллы в
aspnet_client" здесь бесполезен. Организации, которые строят detection исключительно на серверной телеметрии Exchange, будут узнавать о компрометации из уведомления регулятора, а не из собственного SIEM. Я считаю, что для on-premises Exchange единственный реалистичный подход - мониторинг на уровне OWA-сессий и почтового потока в связке с UEBA. Кто ограничивается только серверными логами, рискует пропустить весь класс browser-side атак, которых в Exchange с каждым годом становится больше. Тематический тред с playbook'ом по Exchange TTP - на codeby.net.
Последнее редактирование модератором: