Почтовая инфраструктура компаний редко попадает в список приоритетов у ИТ-отдела, если она годами работает без сбоев. Именно эта особенность стала причиной, по которой критическая уязвимость в Microsoft Exchange по состоянию на 1 сентября всё ещё активна почти на 22 тысячах серверов по всему миру. Речь про CVE-2026-62911, обход аутентификации, который открывает злоумышленнику доступ ко всем почтовым ящикам организации, даже когда у него нет ни одной действующей учётной записи в этой организации.
Масштаб проблемы: сколько серверов остаются открытыми прямо сейчас
По данным ежедневных сканирований интернета, на 31 августа зафиксировано 21 899 уникальных IP-адресов с признаками уязвимой версии Exchange. Это число почти не сдвигается с момента раскрытия проблемы 11 августа, что для критической уязвимости с CVSS 8.0 является тревожным сигналом. Лидируют по числу открытых серверов США, там насчитывается около 6200 уязвимых инстансов, следом идёт Германия примерно с 5100 серверами. Ещё несколько сотен уязвимых узлов приходится на Великобританию, Канаду, Австрию и Францию, а более мелкие кластеры разбросаны по десяткам других стран, включая Италию, Нидерланды и Китай. Такая география показывает, что проблема не локальная, а системная: организации любого масштаба откладывают патчинг почтовых серверов, потому что процесс обновления Exchange воспринимается как рискованный и трудоёмкий. Официальный вектор уязвимости выглядит так: сетевая доступность, низкая сложность атаки, необходимость низких привилегий у атакующего и обязательное действие жертвы, при высоком влиянии на конфиденциальность, целостность и доступность данных. Именно сочетание "низкая сложность плюс сетевая доступность" объясняет, почему за три недели с момента раскрытия число уязвимых узлов почти не сократилось: массовое сканирование интернета находит такие серверы быстрее, чем на них успевают поставить патч.
Как устроен обход аутентификации и почему он опасен
CVE-2026-62911 относится к категории CWE-294, обход аутентификации через перехват и повтор данных сессии. Уязвимость связана с внутренним компонентом MRSProxy, который отвечает за перемещение почтовых ящиков между серверами Exchange и который оказался доступен из интернета без должного применения Extended Protection for Authentication. Из-за этого пробела злоумышленник получает возможность перехватывать и повторно использовать NTLM-учётные данные машинного аккаунта самого сервера Exchange, фактически обходя проверку подлинности целиком. Дальнейшее развитие атаки открывает путь к чтению и отправке писем от имени любого пользователя организации, выгрузке вложений и доступу к административным функциям сервера. Уязвимость впервые была продемонстрирована на состязании Pwn2Own в Берлине специалистами инициативы по поиску уязвимостей нулевого дня, а позднее в открытом доступе появился код, эксплуатирующий эту цепочку, что резко сократило время, за которое сканирование интернета переходит в реальные атаки. Исследователи, ответственные за раскрытие, публично не согласились с исходной оценкой производителя о низкой вероятности практической эксплуатации: рабочий код появился в сети менее чем через три недели после выхода патча, а значит окно между теоретическим описанием проблемы и реальными атаками измеряется днями, а не месяцами. Отдельно стоит подчеркнуть, что формально Microsoft описывает проблему как повышение привилегий, а не как удалённое выполнение кода без авторизации, однако в цепочке с другими слабостями Exchange, включая внешний контроль пути к файлу при репликации почтовых ящиков, обход аутентификации превращается в полноценный плацдарм для закрепления в системе.
Какие версии Exchange затронуты и какие сборки закрывают брешь
Под ударом оказались локальные развёртывания Exchange без облачной части, а именно Exchange Server 2016 с последним накопительным обновлением, Exchange Server 2019 в двух актуальных ветках обновлений и Exchange Server Subscription Edition в базовой сборке. Августовский цикл обновлений безопасности принёс исправленные версии для каждой из веток:
- Exchange Server 2016 CU23 закрывается сборкой 15.1.2507.72;
- Exchange Server 2019 CU14 закрывается сборкой 15.2.1544.44;
- Exchange Server 2019 CU15 закрывается сборкой 15.2.1748.49;
- Exchange Server Subscription Edition RTM закрывается сборкой 15.2.2562.46.
Обходного механизма защиты через Exchange Emergency Mitigation для этой уязвимости не существует, поэтому единственный рабочий путь закрыть брешь состоит в установке соответствующего накопительного обновления и августовского патча безопасности поверх него. Проверять стоит не номер накопительного обновления как таковой, а именно точный номер сборки: более ранние подверсии внутри одного и того же CU остаются эксплуатируемыми даже после формального обновления до актуального CU. Здесь кроется частая ловушка: поле AdminDisplayVersion, которое выводит командлет Get-ExchangeServer, отражает только версию накопительного обновления и не обновляется после установки августовского патча безопасности, поэтому администратор увидит в консоли прежний номер сборки, даже когда патч уже стоит. Реальную версию, включающую патч безопасности, показывает файл ядра установщика: команда Get-Command Exsetup.exe с последующим обращением к его FileVersionInfo выводит точный номер сборки, который и нужно сверять с таблицей исправленных версий выше построчно для каждого сервера организации, а не для одного узла из массива. Тот же результат даёт запуск Health Checker, который читает версию из файла, а не из атрибута каталога, и потому не вводит администратора в заблуждение. Отдельного внимания требуют серверы на архитектуре x64 с ролью почтовых ящиков и ролью клиентского доступа, объединённых на одной машине, поскольку именно там расположен уязвимый компонент репликации почтовых ящиков, тогда как чисто транспортные роли риску не подвержены напрямую.
Как найти открытые OWA и ECP инстансы в собственной инфраструктуре
Первый шаг любого аудита начинается не с самого сервера, а с внешнего взгляда на него, то есть с того, что видит из интернета случайный сканер. Сервисы для полнотекстового поиска по интернет-хостам позволяют проверить, какие узлы организации отвечают на внешние запросы к веб-интерфейсам Outlook Web App и Exchange Control Panel: достаточно искать по открытым портам 443 и 444, по характерным заголовкам ответа сервера и по строкам продукта в баннере HTTP. Такой запрос быстро показывает, сколько именно узлов компании смотрит в интернет напрямую, без пограничного шлюза приложений на входе и без ограничения доступа по IP. Отдельно стоит проверить путь /ecp и путь /EWS/mrsproxy.svc: если эта конечная точка отвечает без ограничений сети, это прямой признак того, что уязвимый компонент доступен извне и требует немедленного патчинга или временного закрытия доступа на уровне файрвола. Аудит стоит повторять регулярно, а не разово, потому что новые узлы и тестовые серверы нередко разворачивают в обход общей политики публикации сервисов. Полезная практика: сверять список найденных внешних IP-адресов с реестром активов организации раз в неделю, а не полагаться на память ИТ-отдела о том, какие серверы вообще стоят на периметре. Отдельно проверяется заголовок ответа Server в HTTP-ответе на корневой запрос к сайту OWA: если он выдаёт номер версии IIS и билд Exchange открытым текстом, это дополнительная подсказка для потенциального атакующего, и такую информацию стоит скрывать на уровне настроек веб-сервера независимо от факта патчинга самой уязвимости.
Порядок обновления Exchange Subscription Edition без остановки почты
Организациям, перешедшим на Subscription Edition, обновление стоит проводить по отработанной последовательности, которая минимизирует простой почтовой службы. Сначала выполняется резервное копирование баз данных и конфигурации сервера, а также фиксируется точный номер сборки через файл Exsetup.exe, чтобы иметь точку отката. Далее запускается Microsoft Exchange Health Checker, который заранее выявляет проблемы с сертификатами, местом на диске и состоянием служб, способные сорвать установку патча. Ключ /mode:Upgrade относится только к установке накопительных обновлений и здесь не применяется: августовский патч безопасности поставляется отдельным файлом-установщиком и запускается напрямую из командной строки с правами администратора, без ключей смены режима. Перед запуском установщика на любом узле, входящем в DAG, роли этого сервера обязательно переводятся в режим обслуживания вручную: сначала выполняется слив очередей транспортной службы, затем через Set-ServerComponentState активные компоненты сервера переключаются в неактивное состояние с указанием причины Maintenance, и только после этого пассивные копии баз данных перемещаются на соседний узел. Автоматически ничего из этого установщик не делает, поэтому попытка обновить сервер в DAG "на живую", рассчитывая на встроенную логику установки, обрывает маршрутизацию почты для всех пользователей, чьи ящики в этот момент обслуживает патчуемый узел. После завершения установки и перезапуска служб те же компоненты вручную возвращаются в активное состояние, и только тогда обновление переходит к следующему узлу. Такой порядок держит почтовую службу доступной для пользователей на протяжении всего цикла обновления. После установки обязательно повторно запускается Health Checker и проверяется точный номер сборки, чтобы убедиться в успешном закрытии уязвимости. На каждый узел закладывается окно обслуживания от сорока минут до полутора часов в зависимости от объёма баз данных и скорости дисковой подсистемы, а на организацию с четырьмя узлами в DAG весь цикл обновления укладывается в одну рабочую ночь при последовательном подходе. Пропускать проверку сертификатов на этапе Health Checker не стоит даже под давлением сроков: истёкший или неверно привязанный сертификат на службе транспорта после установки патча способен остановить приём почты сильнее, чем сама уязвимость, которую призвано закрыть обновление.
На что смотреть в логах IIS при поиске следов эксплуатации
Логи IIS на сервере Exchange хранятся в каталоге инспекции протокола HTTP и остаются главным источником информации о том, пытался ли кто-то воспользоваться обходом аутентификации до установки патча. В первую очередь стоит выгрузить записи с обращениями к этому эндпоинту за последние недели и отфильтровать те, где код ответа сервера равен 200, а метод запроса указывает на аутентификацию через NTLM без сопутствующей повторной проверки через Kerberos. Подозрительным признаком считается серия обращений к одному и тому же эндпоинту с разных IP-адресов, но с идентичными токенами авторизации в заголовке: именно так выглядит перехват и повторное использование данных сессии, на котором строится вся атака. Отдельного внимания заслуживают записи о создании новых правил пересылки почты, новых учётных записей с административными ролями или изменении разрешений на почтовые ящики сразу после подозрительных обращений к этому компоненту, поскольку это типичное продолжение атаки после успешного обхода проверки подлинности. Логи стоит сопоставлять с журналом событий безопасности Windows на предмет успешных входов под машинным аккаунтом сервера в необычное время суток, так как легитимные процессы Exchange обычно используют этот аккаунт по предсказуемому расписанию. Стандартные поля лога IIS, такие как cs-uri-stem, sc-status, cs-username и time-taken, стоит выгружать отдельным отчётом за период с момента раскрытия уязвимости одиннадцатого августа: аномально короткое время обработки запроса к mrsproxy.svc в сочетании с кодом ответа 200 при пустом или нетипичном значении поля cs-username часто указывает именно на автоматизированную попытку эксплуатации, а не на обращение живого пользователя через привычный клиент. Разумный минимум глубины хранения таких логов для расследования подобных инцидентов составляет девяносто дней, поскольку разрыв между первичным проникновением и его обнаружением в почтовой инфраструктуре нередко превышает месяц.
Почему инфраструктура годами остаётся без обновлений
Причина, по которой почтовые серверы задерживаются на устаревших сборках дольше других систем, лежит не столько в технической сложности патча, сколько в цене простоя для бизнеса. Почта считается критичным сервисом, а любое окно обслуживания требует согласования с руководством и предупреждения сотрудников, из-за чего обновление откладывается до ближайшего планового окна, которое может наступить через месяцы. Разработчики платформы решают эту проблему регулярным циклом патчей по вторникам, но между выходом патча и его установкой на конкретном сервере часто проходит куда больше времени, чем длится окно между публикацией уязвимости и появлением рабочего эксплойта в открытом доступе. Разрыв между этими двумя скоростями и формирует ту самую армию из тысяч открытых серверов, которую регулярно фиксируют сканеры интернета. Организациям, которые не готовы обновлять Exchange немедленно, стоит хотя бы временно закрыть внешний доступ к пути mrsproxy.svc на уровне пограничного шлюза приложений или файрвола, оставив его доступным только внутри локальной сети, где риск перехвата аутентификационных данных значительно ниже.
Патч закрывает конкретную технику атаки, но сама логика уязвимости показывает системную проблему инфраструктуры, которая годами работает по принципу "работает, не трогай". Регулярный аудит внешнего периметра, привычка сверять точный номер сборки, а не только версию накопительного обновления, и разбор логов IIS хотя бы раз в квартал снижают шанс оказаться в числе тех самых 22 тысяч серверов, попавших в статистику сканирования.