CVE-2023-23397: Outlook ворует NTLM-хэш без единого клика
Критическая zero-click уязвимость в Outlook перехватывает NTLM-хэши через приглашение в календаре. Разбираем временные меры до патча и что это значит для Exchange-инфраструктур.
CVE-2023-23397 - критическая zero-click уязвимость в Microsoft Outlook, позволяющая перехватить NTLM-хэш через специально сформированное приглашение в календаре, патч ожидается в Patch Tuesday марта 2023
Microsoft на этой неделе раскрыла CVE-2023-23397 - уязвимость в Outlook с CVSS 9.8 и статусом «эксплуатируется в дикой природе». Патч обещан в Patch Tuesday марта 2023, то есть примерно через три недели. Три недели - это долго, особенно с учётом того, что за это время можно узнать про атаку.
Мы сразу полезли разбираться, потому что у нескольких клиентов Exchange ещё живёт - кто-то не успел мигрировать, кто-то осознанно держит on-premise. Для таких инфраструктур история острее, чем для тех, кто давно перешёл на облачную почту.
Как это работает
Механика нестандартная. Атакующий отправляет жертве приглашение в Outlook-календарь (.msg) с особым свойством - путём до UNC-ресурса в поле напоминания. Когда Outlook обрабатывает это приглашение, он автоматически пытается подключиться к указанному UNC-пути, чтобы воспроизвести звук напоминания. При этом Windows отправляет NTLM-хэш учётных данных текущего пользователя на сервер атакующего.
Никакого клика. Никакого открытия вложения. Достаточно того, что письмо попало в почтовый ящик и Outlook его получил - Preview Pane тоже триггерит. Если пользователь вообще не открывал письмо, это не помогает.
Дальше атакующий либо крекает хэш офлайн, либо использует его для NTLM relay - переотправляет хэш другому сервису в сети, который принимает NTLM-аутентификацию. Это позволяет аутентифицироваться от имени жертвы без знания пароля.
В корпоративной сети с Active Directory, где NTLM relay исторически не заблокирован, это прямой путь к lateral movement.
Что мы проверяли у клиентов
Первый вопрос: где вообще стоит Outlook. Казалось бы, очевидно - все используют почту. Но в контексте CVE-2023-23397 важны детали: это корпоративный Outlook с Exchange on-premise или Microsoft 365, какая версия клиента, есть ли централизованное управление.
Exchange on-premise + Outlook. Это наиболее уязвимый сценарий. NTLM-аутентификация между Outlook и Exchange включена по умолчанию, relay между сервисами внутри AD-домена - классический вектор. У двух клиентов из нашей базы именно такая конфигурация.
Microsoft 365 + Outlook. Ситуация немного лучше: Exchange Online не принимает NTLM relay, поэтому часть атаки отрезана. Но хэш всё равно уходит на подконтрольный атакующему сервер - и если внутри сети есть ресурсы, принимающие NTLM (файловые шары, сервисы), то relay туда никуда не делся.
Версии Outlook. Уязвимы Outlook 2013, 2016, 2019, Outlook for Microsoft 365 на Windows. Outlook на Mac и мобильные клиенты не затронуты - там другая реализация обработки напоминаний.
Временные меры до патча
Ждать марта просто так не вариант. Набор мер, который мы применяем у клиентов прямо сейчас.
Первое - заблокировать исходящий SMB (445/tcp) на периметре. Это убирает возможность NTLM relay наружу, к серверам атакующего в интернете. Во многих сетях этот порт уже закрыт исходящим файрволом - но нужно проверить, а не предполагать. Трафик на 445 изнутри наружу в принципе не должен существовать в нормальной конфигурации.
Второе - добавить Protected Users group. Все привилегированные аккаунты - в группу Protected Users в AD. Это не позволяет использовать NTLM для их аутентификации вообще. Мера жёсткая, может сломать некоторые legacy-сервисы, поэтому начинать стоит с сервисных и административных учёток, а не с рядовых пользователей.
Третье - заблокировать NTLM outbound. Через Group Policy можно ограничить исходящую NTLM-аутентификацию с рабочих станций к внешним серверам. Политика «Network Security: Restrict NTLM: Outgoing NTLM traffic to remote servers» - значение «Deny all». Аккуратно: нужно сначала поставить в режим аудита и посмотреть что сломается.
Четвёртое - скрипт Microsoft для проверки. Вендор опубликовал PowerShell-скрипт для поиска подозрительных элементов в Exchange-ящиках с нестандартными UNC-путями в CalendarItem. Запустили, прошлись - признаков активной эксплуатации не нашли. Но это скрипт «поискать следы после факта», а не защита.
NTLM relay в 2023: почему это до сих пор работает
Немного печальный контекст. NTLM relay как техника - не новость, ей лет двадцать. Microsoft долго и методично закрывала векторы: LDAP signing, EPA для Exchange, SMB signing. Но именно этот вектор - через Outlook, без какого-либо взаимодействия пользователя - оказался незакрытым.
Для инфраструктур на Exchange on-premise это особенно болезненно: там NTLM исторически везде, отключить его без подготовки невозможно, а включить Kerberos-only - отдельный проект на несколько недель.
Те клиенты, с которыми мы обсуждаем план перехода на отечественную почтовую платформу - RuPost, VK WorkSpace, Яндекс 360 для бизнеса - получают в этой истории дополнительный аргумент. Не потому что там безопаснее по определению, а потому что NTLM relay как вектор там просто не существует: другая аутентификационная модель, другой стек.
Это не главный аргумент в пользу миграции - там хватает других соображений из аудита. Но как иллюстрация того, что on-premise Exchange тянет с собой целый класс Windows-специфичных рисков, история показательная.
Патч ждём в марте. До тех пор - блок исходящего SMB и сервисные аккаунты в Protected Users. Это минимум, который можно сделать за час и который реально снижает риск.