Что делать с уязвимостью Outlook CVE-2023-23397

CVE-2023-23397 закрывается обновлением Outlook для Windows: обновлённый Exchange сам по себе не исправляет уязвимый клиент. Я покажу, как проверить установки, просканировать почтовые элементы по инструкции Microsoft и разбирать журналы без ложных выводов. Один успешный вход в журнале ещё не доказывает эксплуатацию.

Как работает CVE-2023-23397 в Outlook

CVE-2023-23397 — уязвимость повышения привилегий в Outlook для Windows. Злоумышленник присылает специально сформированное письмо, задаёт в расширенном свойстве MAPI путь к SMB-ресурсу на своём сервере, а Outlook обращается к нему, когда срабатывает напоминание. При таком обращении клиент отправляет данные аутентификации Net-NTLMv2. Человеку не нужно открывать письмо, нажимать ссылку или запускать вложение. Проблема находится в Outlook для Windows; я проверяю клиентские установки вместе с общей проверкой информационной безопасности, а не ограничиваюсь статусом почтового сервера.

Полученные данные не равны готовому паролю и не дают злоумышленнику автоматический доступ ко всей сети. Их могут попытаться передать дальше для проверки подлинности на другом сервисе, принимающем NTLM, либо исследовать офлайн, чтобы подобрать пароль. Это не Pass-the-Hash: Microsoft отдельно указывает, что утёкший Net-NTLMv2 нельзя использовать этим способом. Дальше всё зависит от того, какие сервисы доступны, какие учётные данные применяет пользователь и как настроена аутентификация. Риск серьёзный, но формула «одна утечка — вся сеть захвачена» технически неверна.

В бюллетене Microsoft уязвимость описана для Outlook под Windows; Outlook для macOS, iOS, Android и веб-версия не указаны как затронутые. Обновить нужно именно Outlook для Windows — независимо от того, где размещён ящик: на Exchange Server, в Exchange Online или у другого провайдера. Обновление Exchange Server за март 2023 года добавляет защиту на уровне обработки новых сообщений, но не заменяет исправление Outlook на рабочих местах. Это различие легко пропустить, если смотреть только на серверную консоль.

Как проверить версии Outlook и обновления

Начинаю с инвентаризации всех компьютеров, где установлен классический Outlook для Windows. Для каждого фиксирую редакцию Office, канал обновления и номер сборки; отдельно отмечаю устройства, которые давно не подключались к системе управления или не получают обновления. Одного слова «Outlook 2019» недостаточно: статус зависит от конкретной редакции и её сборки. Microsoft публикует перечень обновлений для затронутых продуктов, поэтому установленную сборку нужно сравнивать с актуальной записью MSRC, а не с датой покупки компьютера.

Номер версии можно посмотреть в Outlook через «Файл» → «Учётная запись Office» → «О программе Outlook». В управляемой среде я дополнительно сверяю инвентаризацию из системы управления устройствами с фактическим состоянием на рабочих местах: запись в отчёте может отставать от машины, если она долго была выключена или давно не выходила в сеть. Не использую winword.exe /version как проверку Outlook: это не штатная команда получения сборки Outlook. Команды полезны, когда они документированы и отвечают на нужный вопрос; выдуманная команда только красиво выглядит в чек-листе.

После сверки устанавливаю исправление Outlook способом, который принят для конкретного канала Office, затем повторно проверяю сборку и запуск приложения. Windows Update не всегда является единственной точкой управления обновлениями Office: настройки могут задаваться средствами Office, политикой организации или системой управления устройствами. Поэтому я не считаю галочку «автоматически обновлять Windows» доказательством, что уязвимость устранена. Если отдельную машину нельзя обновить сразу, её отмечают как исключение с владельцем и сроком; временные меры берут из рекомендации Microsoft, не подменяя ими постоянное исправление. Минимальная исправленная сборка различается между редакциями и каналами Office, поэтому универсальный номер без привязки к установленному продукту будет ошибкой. Я сохраняю исходную сборку и ссылку на ту строку MSRC, по которой сверял обновление.

• Составьте перечень компьютеров с Outlook для Windows.
• Зафиксируйте редакцию Office, канал и номер сборки.
• Сверьте сборки со страницей CVE в MSRC.
• Установите обновления Outlook и проверьте результат.
• Отдельно проверьте машины, пропущенные системой управления.

Условный разбор для офиса на 14 рабочих мест

Покажу порядок действий на условном примере: московская компания «ДетальМаркет», 14 рабочих мест. Это вводные для разбора, а не заявление о проведённом аудите. Я не буду придумывать, на скольких компьютерах нашёлся старый Outlook, были ли подозрительные входы и сколько заняло исправление: такие выводы можно делать только после проверки конкретной инфраструктуры.

Первым делом я разделил бы список на рабочие станции с Outlook для Windows и остальные устройства. Для 14 мест такой перечень можно проверить вручную, но я всё равно записал бы модель учёта: имя устройства, редакцию Office, сборку, дату последнего обновления и результат перепроверки. Затем выяснил бы, где находятся почтовые ящики — в Exchange Server, Exchange Online или другом сервисе. Это нужно не для того, чтобы «проверить Exchange вместо Outlook», а чтобы выбрать правильный способ поиска вредоносных почтовых элементов.

Если компания использует Exchange Server или Exchange Online, для поиска Microsoft предлагает скрипт, который проверяет почтовые ящики на элементы со свойством PidLidReminderFileParameter и выводит найденные задачи, письма и элементы календаря. Администратор анализирует найденный путь и при необходимости изменяет или удаляет элемент. Результат скрипта — не приговор пользователю и не автоматическое доказательство, что данные уже использовали; это основание для дальнейшего расследования. Если почта размещена в другой системе или сообщение лежит в локальном PST, нельзя обещать, что проверка Exchange охватит эти данные.

После проверки я отдельно закрыл бы обновления Outlook на каждом затронутом компьютере, а затем повторно подтвердил сборки. Если Exchange Server также требует обновления, его устанавливают как отдельную работу: серверное исправление даёт дополнительную защиту новых сообщений, но клиентскую CVE не закрывает. В итоговой ведомости должны быть видны проверенные устройства, найденные почтовые элементы, применённые обновления и оставшиеся исключения. Для офиса на 14 мест это обычный управляемый список, а не повод изображать масштабный инцидент без свидетельств.

Какие следы искать в почте и журналах

Я начинаю не с перебора всех событий Windows, а с поиска самого подозрительного элемента в почтовом ящике. Microsoft отмечает, что традиционная проверка конечного устройства может оставить мало следов, поэтому доступен специальный скрипт поиска для Exchange. У него есть границы: он сканирует выбранные почтовые ящики, но не локальные PST и не любые сторонние почтовые системы. Пустой отчёт полезен, однако сам по себе не доказывает, что все источники проверены и атаки не было.

Для сетевой части Microsoft советует смотреть журнал Microsoft-Windows-SMBClient/Connectivity и проверять поле ServerName в событиях 30800, 30803, 30806, 30804 и 31001. Неожиданное имя удалённого узла в подходящее время — повод сопоставить устройство, пользователя, почтовый элемент и сетевую телеметрию. В отдельных случаях Windows может перейти к WebDAV, если SMB-соединение не удалось; следы создания процесса в таком сценарии помогают увидеть попытку обращения, но не подтверждают, что учётные данные были похищены. Время и контекст здесь важнее охоты за одним «магическим» событием.

Событие безопасности 4624 означает успешный вход и содержит сведения для сопоставления, включая учётную запись и данные о процессе или источнике, когда они доступны. Событие 4625 описывает неудачный вход. Эти определения полезны для разбора аномалий, но ни 4624, ни тип сетевого входа 3 не являются индикатором именно CVE-2023-23397. Нужно сравнивать время событий с напоминанием, именем удалённого SMB-узла, пользователем, журналами почты и сетевыми записями. Случайные всплески DNS или отдельный запуск PowerShell без такой связи не дают основания объявлять эксплуатацию.

• Просканируйте доступные ящики скриптом Microsoft.
• Проверьте ServerName в журналах SMBClient/Connectivity.
• Сопоставьте время, пользователя, устройство и найденный элемент.
• Читайте события 4624 и 4625 как контекст, не как доказательство CVE.

Как закрыть риск и реагировать на находки

Приоритет первый — исправить Outlook для Windows на всех затронутых устройствах. Это требование не зависит от того, где размещена почта и поддерживает ли организация NTLM. Затем проверяю почтовые элементы скриптом Microsoft, разбираю найденные пути и смотрю связанные сетевые и аутентификационные журналы. Обновление Exchange Server может быть полезной дополнительной мерой для новых сообщений, но в плане работ оно идёт отдельно от клиентского исправления. Для общей картины почтовых рисков пригодится и наш разбор защиты корпоративной почты.

Если подозрительный элемент найден, сначала сохраняю данные расследования и выясняю, куда он указывал, кто получил письмо и на каком устройстве сработало напоминание. Если признаки показывают возможное использование учётных данных, проверяю связанные входы, почтовые правила и права на папки, после чего меняю пароль и отзываю активные сессии по принятому плану реагирования. Сброс пароля сам по себе не удаляет уже созданные права доступа к почтовым папкам, поэтому считать его универсальной уборкой нельзя. Изоляция компьютера нужна при подтверждённых признаках инцидента и должна учитывать, как организация продолжит работу.

В плановой работе я закрепляю владельца обновлений Office, способ проверки сборок и порядок обработки исключений. Для инцидентов отдельно записываю, кто запускает скрипт Microsoft, кто оценивает найденные элементы и где сохраняются логи. После обновления повторно сверяю перечень машин и закрываю только подтверждённые пункты; фраза «всё поставили» без списка устройств ничего не проверяет. Если организация использует и другие почтовые платформы, их проверяют отдельным методом, а не распространяют результат Exchange-сканирования на всю инфраструктуру.

• Обновите Outlook для Windows.
• Проверьте почтовые элементы по инструкции Microsoft.
• Сопоставьте находки с сетевыми и входными журналами.
• При подтверждённой компрометации проверьте сессии и права почты.

Частые вопросы