Microsoft доработала защиту от эксплуатации 0-day в серверах Exchange

Microsoft доработала защиту от эксплуатации 0-day в серверах Exchange

Microsoft доработала защиту от эксплуатации 0-day в серверах Exchange

В Microsoft заявили, что корпорация улучшила защиту от эксплуатации недавно обнародованных уязвимостей нулевого дня в серверах Exchange. Полноценного патча, к сожалению, разработчики до сих пор не выпустили.

Таким образом, Microsoft пересмотрела правило блокировки в IIS Manager из “.*autodiscover\.json.*Powershell.*" в "(?=.*autodiscover\.json)(?=.*powershell)”.

Техногигант привел список шагов для тех администраторов, которые планируют добавить правило URL Rewrite:

  • Открыть IIS Manager
  • Выбрать «Веб-сайт по умолчанию» (Default Web Site)
  • В Feature View нажать URL Rewrite
  • В Actions кликнуть на Add Rule(s) (добавить правило)
  • Выбрать Request Blocking (запрос блокировки) и нажать OK
  • Добавить строку “(?=.*autodiscover\.json)(?=.*powershell)” (без кавычек)
  • Выбрать регулярное выражение (Regular Expression) в разделе Using
  • Выбрать «прерывать запрос» (Abort Request) в разделе «Как блокировать» и нажать OK
  • Раскрыть правило и выбрать с паттерном (?=.*autodiscover\.json)(?=.*powershell). Нажать «Редактировать» под пунктом «Состояния»
  • Изменить ввод с “{URL}” на “{UrlDecode:{REQUEST_URI}}” и нажать OK

В качестве альтернативы пользователи могут запустить специальный инструмент — EOMTv2.ps1, который Microsoft тоже обновила.

Напомним, что о незакрытых уязвимостях в Microsoft Exchange стало известно в конце прошлого месяца. Их отслеживают под номерами ZDI-CAN-18333 (8,8 балла по шкале CVSS) и ZDI-CAN-18802 (6,3 балла по шкале CVSS).

MAX Desktop проверили на слежку за VPN, сенсация не состоялась

Пользователь Хабра Slava_B протестировал поведение десктопного клиента MAX в Windows и не обнаружил признаков того, что мессенджер распознаёт VPN при маршрутизации трафика через роутер. Зато приложение читает ряд системных параметров и идентификаторов компьютера.

Эксперимент провели 8 сентября 2026 года. Windows-компьютер подключили к роутеру Keenetic, который самостоятельно распределял трафик: российские ресурсы открывались напрямую, а часть остальных соединений уходила через OpenConnect-туннель на европейский VPS.

В самой Windows не было ни VPN-клиента, ни виртуального адаптера, ни соответствующих маршрутов.

За клиентом MAX следили с помощью Process Monitor, Wireshark и TCPView, а трафик на удалённом сервере записывали через tcpdump. Исследователь выяснил, что приложение запускает процессы MAX.exe и MAX-service.exe, связывающиеся между собой через локальный порт. Клиент подключался к инфраструктуре MAX/ONEME, сервису AppTracer и системам для звонков.


MAX и его служебный процесс многократно читали MachineGuid — стабильный идентификатор установки Windows. Программа также получала имя компьютера, настройки proxy/PAC, собственные device ID и сведения о микрофонах и камере. Впрочем, подобные данные могут использоваться для диагностики, антифрода, подключения через корпоративный прокси и работы звонков.


Главный результат успокаивает: соединения MAX не появились на VPN-интерфейсе VPS, а обращений к сервисам определения внешнего IP, Telegram, WhatsApp (принадлежит корпорации Meta, признанной экстремисткой и запрещённой в России) или другим ресурсам для проверки маршрута исследователь не выявил. Браузеры клиент тоже не запускал.

При этом автор подчёркивает: содержимое TLS-трафика не расшифровывалось, поэтому доказательств передачи MachineGuid или других идентификаторов на сервер нет. Результат относится только к конкретной конфигурации и не показывает, как MAX поведёт себя с VPN-клиентом непосредственно в Windows.

RSS: Новости на портале Anti-Malware.ru