SharePoint уже пропатчен: как проверить обход ToolShell и найти следы взлома

Патч установлен, сервер перезагружен, портал открывается. Возвращать публикацию? Я бы сначала проверил, что происходило до обновления. Я — Семёнов Евгений Сергеевич, директор ООО «АйТи-Фреш». Покажу, как отделить закрытую уязвимость от устранённого взлома: проверить обновления каждого узла, собрать следы, разобраться с закреплением и сменить ключи перед подключением.

Сначала уточняю, какой именно июльский патч установлен

Здесь речь об обходе исправлений от 8 июля 2025 года. Исходная цепочка ToolShell связана с CVE-2025-49706 и CVE-2025-49704; последующие варианты получили CVE-2025-53770 и CVE-2025-53771. Microsoft признала первоначальную защиту неполной и выпустила дополнительные обновления. Поэтому запись «июльский патч установлен» без номера KB ничего не решает. SharePoint Online эта цепочка не затронула; разбор относится к локальному SharePoint Server, в том числе размещённому на виртуальных машинах у провайдера. [Рекомендации MSRC](https://www.microsoft.com/en-us/msrc/blog/2025/07/customer-guidance-for-sharepoint-vulnerability-cve-2025-53770).

Я разделяю два вопроса. Первый: закрыты ли известные способы первоначального проникновения? Второй: сохранилось ли у атакующего то, что он получил раньше? Webshell — серверный файл для выполнения действий злоумышленника — может пережить обновление. Украденные ASP.NET MachineKey тоже не становятся новыми после установки KB. В исследованных атаках отдельный ASPX-файл как раз извлекал криптографические секреты. Поэтому удаление такого файла не отменяет уже состоявшуюся утечку ключей. [Исследование Eye Security](https://labs.eye.security/sharepoint-under-siege/).

Ниже — исторические ориентиры экстренного исправления, а не целевые версии для эксплуатации сегодня. На 5 сентября 2026 года устанавливать нужно актуальные применимые накопительные обновления. Более того, поддержка SharePoint 2016 и 2019 завершилась 14 июля 2026 года. Старую ферму я рассматриваю вместе с планом перехода на поддерживаемую платформу: устранение ToolShell не продлевает жизненный цикл продукта. [Таблица обновлений](https://learn.microsoft.com/en-us/officeupdates/sharepoint-updates), [окончание поддержки](https://learn.microsoft.com/en-us/lifecycle/end-of-support/end-of-support-2026).

• SharePoint Server 2016: KB5002760 и KB5002759; сборка основного экстренного пакета — 16.0.5513.1001.
• SharePoint Server 2019: KB5002754 и KB5002753; сборка основного экстренного пакета — 16.0.10417.20037.
• SharePoint Server Subscription Edition: KB5002768; сборка — 16.0.18526.20508. В таблице Microsoft эти экстренные выпуски датированы 21 июля 2025 года.

До перезагрузки и очистки сохраняю то, что поможет расследованию

При подозрении на проникновение я сначала убираю публичную публикацию и ограничиваю связность подозрительных узлов. Просто удалить сервер из балансировщика недостаточно: могут остаться прямой адрес, альтернативное имя и исходящие соединения. Доступ для расследования оставляю через контролируемый административный маршрут, отдельно проверяю работу EDR. Если уже идёт разрушительная активность, локализация важнее красивой последовательности сбора. Но при спокойном состоянии немедленный перезапуск лишит нас части сведений о процессах, соединениях и загруженных сборках.

До лечения сохраняю журналы IIS, ULS, Windows, антивируса, EDR и пограничного прокси. Фиксирую активные процессы, сетевые соединения, конфигурацию IIS и задания планировщика; при необходимости подключаю специалиста для получения памяти и образов дисков. Рабочие копии отделяю от оригиналов, записываю время получения и SHA-256. Снимок виртуальной машины полезен как вспомогательная точка, но я не считаю его автоматически полноценным комплектом доказательств или гарантированно чистой резервной копией.

Период поиска выбираю по доступной истории, а не по дате громкой новости. Microsoft указывает на возможные попытки эксплуатации исходной цепочки уже 7 июля 2025 года. Значит, начинать только с 18 июля рискованно. Если журналов за ранний период нет, прямо записываю этот пробел. Пустая выборка за последние семь дней не рассказывает, что происходило месяц назад. Особенно когда обновление установили поздно, а журналы давно перезаписались. [Хронология Microsoft Threat Intelligence](https://www.microsoft.com/en-us/security/blog/2025/07/22/disrupting-active-exploitation-of-on-premises-sharepoint-vulnerabilities/).

• Зафиксировать все узлы фермы, адреса публикации, веб-приложения и доступные источники телеметрии.
• Сохранить артефакты до удаления файлов, обновления компонентов и перезапуска IIS.
• Отдельно записать отсутствующие журналы и интервалы, которые проверить невозможно.

Проверяю обновление на каждом узле, а не по одному номеру фермы

После сохранения исходного состояния составляю таблицу: сервер, роль, установленные пакеты, результат конфигурирования. Проверяю веб-узлы и серверы приложений. Для SharePoint 2016/2019 нужны обе части обновления — STS и WSSLOC; языковая часть требуется и английской установке без дополнительных языков. При переходе на текущие накопительные пакеты устанавливать все промежуточные июльские KB отдельно не нужно. У Subscription Edition с марта 2023 года основные и языковые изменения объединены в один пакет. [Правила комплектации обновлений Microsoft](https://learn.microsoft.com/en-us/officeupdates/sharepoint-updates).

В SharePoint Management Shell с нужными административными правами начинаю с команд ниже. Get-SPProduct -Local выполняю на каждом SharePoint-сервере уже после сбора доказательств: команда актуализирует сведения о локальных продуктах для фермы. Номер BuildVersion записываю для сопоставления, но не использую как единственное доказательство исправленности всех узлов. Проверяю также страницу состояния установленных продуктов и исправлений в Central Administration. [Документация Get-SPProduct](https://learn.microsoft.com/en-us/powershell/module/microsoft.sharepoint.powershell/get-spproduct?view=sharepoint-ps). ```powershell Get-SPProduct -Local (Get-SPFarm).BuildVersion ```

Установка бинарников должна сопровождаться завершением конфигурационного этапа через SharePoint Products Configuration Wizard или предусмотренный процедурой PSConfig. Проверяю результат по каждому серверу, журналы upgrade и отсутствие незавершённого обновления баз. Затем запускаю актуальную проверку уязвимостей с учётными данными, охватывая отдельные узлы. Это полезнее одного запроса через балансировщик. Ответ 403 на известный URL может означать блокировку прокси, а не исправление самого SharePoint. Боевой RCE-эксплойт ради зелёной галочки на рабочей ферме я не запускаю. [Этапы обновления SharePoint](https://learn.microsoft.com/en-us/sharepoint/upgrade-and-update/software-updates-overview).

• У всех узлов проверен согласованный комплект обновлений.
• Конфигурационный этап завершён; ошибки upgrade разобраны.
• Проверка охватывает серверы за балансировщиком, включая непубличные узлы.

Ищу последовательность действий: запрос, выполнение, файл, закрепление

В HTTP-журналах начинаю с POST к ToolPane.aspx, необычного Referer с SignOut.aspx и обращений к подозрительным ASPX. Это отправные точки поиска, а не готовый приговор: ToolPane существует и для штатной работы, Referer контролирует клиент, HTTP 200 сам по себе не доказывает RCE. Сильнее выглядит связанная по времени последовательность: запрос, запуск команды процессом IIS, создание постороннего файла и последующее обращение к нему. [Исходные наблюдения Eye Security](https://labs.eye.security/sharepoint-under-siege/).

Перед разбором читаю строку #Fields: порядок и состав колонок нельзя угадывать. Время записей W3C — UTC; сопоставляю его с настройками остальных источников. Проверяю наличие cs-uri-query и cs(Referer). Если заголовок не записывался, задним числом он не появится. Тела запросов обычный W3C-журнал тоже не восстановит. За прокси учитываю доверенный источник адреса клиента. Команда ниже только собирает кандидатов из копий журналов: после неё нужны разбор полей и корреляция событий. [Поля W3C в IIS](https://learn.microsoft.com/en-us/iis/configuration/system.applicationHost/log/centralW3CLogFile). ```powershell Get-ChildItem 'E:\IR\IIS' -Filter *.log -File -Recurse | Select-String -Pattern 'ToolPane\.aspx','spinstall[^ /?]*\.aspx','SignOut\.aspx' ```

На диске проверяю каталоги TEMPLATE\LAYOUTS в установленных деревьях C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\15 и \16, корни веб-приложений и bin. Известные ориентиры — spinstall0.aspx и варианты имени, debug_dev.js, IIS_Server_dll.dll. Но сравнение с доверенным набором файлов той же сборки важнее одного шаблона имени. Подозрительные файлы исследую как данные: содержимое, хеш, происхождение, событие создания. Дата изменения ненадёжна как единственный критерий, а легитимная кастомизация тоже может отсутствовать в стандартной поставке.

Дальше проверяю дочерние процессы w3wp.exe, загрузку необычных .NET-сборок, задания планировщика и изменения компонентов IIS. Такие механизмы закрепления Microsoft наблюдала в атаках ToolShell. Если обнаружен доступ к учётным данным или удалённое выполнение на соседних машинах, расширяю расследование за пределы фермы. Подтверждённый вредоносный модуль либо webshell для меня означает установленную компрометацию. Отсутствие файла с известным именем означает лишь отсутствие этого файла в момент проверки. [Артефакты и поведение атакующих](https://www.microsoft.com/en-us/security/blog/2025/07/22/disrupting-active-exploitation-of-on-premises-sharepoint-vulnerabilities/).

Сначала устраняю доступ атакующего, затем окончательно меняю ключи

Ротацию делаю после закрытия входа и устранения найденных механизмов закрепления либо на восстановленной доверенной ферме. Иначе оставшийся сборщик прочитает новые ключи. CISA отдельно подчёркивает этот порядок в рекомендациях от 14 июля 2026 года. Они относятся уже к новой волне эксплуатации SharePoint и не доказывают обход июльского патча 2026 года; здесь полезен именно принцип восстановления. Если ключи меняли раньше как срочную меру, после очистки проверяю необходимость повторной ротации. [Актуальные рекомендации CISA](https://content.govdelivery.com/accounts/USDHSCISA/bulletins/4208511).

Для каждого веб-приложения использую последовательность MSRC: Set-SPMachineKey, затем Update-SPMachineKey. URL в примере замените своим. После успешного распространения ключей перезапускаю IIS на всех SharePoint-серверах в согласованном окне. Параметр -Local здесь не добавляю: несогласованные ключи между узлами ломают работу через балансировщик. Сами значения ключей в отчёт не вывожу. Автоматическое задание ротации не заменяет подтверждения, что экстренная смена действительно завершилась. [Управление MachineKey](https://learn.microsoft.com/en-us/sharepoint/security-for-sharepoint-server/improved-asp-net-view-state-security-key-management). ```powershell Set-SPMachineKey -WebApplication 'https://portal.example' Update-SPMachineKey -WebApplication 'https://portal.example' # После распространения ключей — на каждом SharePoint-сервере: iisreset.exe ```

Отдельно проверяю AMSI и работающий совместимый антивирусный провайдер. С сентября 2025 PU интеграция обязательна для SharePoint 2016/2019/SE, но сканирование тела запроса и Full Mode доступны только Subscription Edition, начиная с 25H1; в Standard ring — с сентября 2025 PU. Для актуальной SE задаю режим отдельно каждому веб-приложению и просматриваю исключения. Затем выполняю документированный безвредный тест интеграции, проверяю блокировку и событие защиты. Такой тест не доказывает исправленность ToolShell. [Настройка и проверка AMSI](https://learn.microsoft.com/en-us/sharepoint/security-for-sharepoint-server/configure-amsi-integration). ```powershell # Только Subscription Edition с поддержкой body scanning: $webApp = Get-SPWebApplication -Identity 'https://portal.example' $webApp.AMSIBodyScanMode = 2 $webApp.Update() $webApp.AMSIExcludedEndpoints ```

Практический разбор: два веб-узла и ложное ощущение законченного обновления

Разберу учебную реконструкцию проекта условного ООО «Вектор», производственной компании на 120 рабочих мест. Это заданный сценарий, а не отчёт о реальном клиентском инциденте или выполненном мной испытании. Историческая дата — 22 июля 2025 года. Ферма: два WFE и один сервер приложений с SharePoint 2019 на Windows Server 2019 Desktop Experience; каждому выделено 4 vCPU, 16 ГБ RAM и диски 100 плюс 150 ГБ. Отдельно работает SQL Server 2019 с 8 vCPU и 32 ГБ RAM. Это конфигурация примера, не универсальный расчёт мощности. [Требования SharePoint 2019](https://learn.microsoft.com/en-us/sharepoint/install/hardware-and-software-requirements-2019).

Портал опубликован по HTTPS через балансировщик, который проверяет доступность страницы и не выполняет предварительную аутентификацию. В сценарии WFE1 получил KB5002754 и KB5002753, а WFE2 остался на пакетах 8 июля — KB5002741 и KB5002739, со сборкой пакета 16.0.10417.20027. Обновление сервера приложений тоже не завершено. Администратор проверил портал несколько раз, получил нормальный ответ и закрыл заявку. Я начинаю с проверки каждого узла: доступность страницы не показывает, какой сервер обслужил запрос и какой комплект обновлений на нём установлен.

В учебном наборе событий на WFE2 за 19 июля заданы POST к ToolPane.aspx в 02:14:31 UTC, запуск командной оболочки от w3wp.exe через секунду и создание spinstall0.aspx ещё через секунду. Содержимое файла извлекает MachineKey; затем есть GET к нему. Дополнительно задано неизвестное согласованной конфигурации задание планировщика. Такая совокупность переводит ситуацию из проверки патча в расследование компрометации. Я считаю доступные ключи раскрытыми, сохраняю артефакты и проверяю остальные узлы, SQL и события использования сервисных учётных записей.

Результат сценария — отказ от возврата старых WFE в эксплуатацию. Восстановление предусматривает новые SharePoint-узлы из доверенных источников, полный комплект исправлений, завершение конфигурации и отдельную проверку переносимых данных и кастомизаций. Старые web.config и системные диски целиком не переносятся. После восстановления меняются MachineKey и затронутые учётные данные, выполняется проверка функций портала с принудительным направлением на каждый WFE. Для пользователей задаётся окно недоступности восемь часов и сутки усиленного наблюдения после внутреннего запуска. Это плановые параметры упражнения, а не измеренное время восстановления или гарантия очистки. В 2026 году такой план дополнительно требует решения по завершившейся поддержке SharePoint 2019.

Возвращаю доступ по проверяемым условиям

При подтверждённом RCE я выбираю восстановление из доверенного основания. Это дороже удаления одного ASPX, зато позволяет заново обосновать доверие к серверу. Само по себе обновление до новой редакции тоже не очищает заражённую систему. При этом восстанавливать каждую ферму после одиночного подозрительного запроса я не предлагаю: сначала нужно понять, был ли запрос заблокирован и какие события последовали. Решение зависит от доказательств и полноты телеметрии, а не от тревожности заголовка.

Если положительных признаков нет, но история неполная, так и формулирую результат: «в доступных источниках компрометация не подтверждена». Обещать чистоту сервера в такой ситуации нельзя. Для публичного портала с длительным непроверяемым периодом я предпочту более консервативное восстановление. Универсального срока «подержать сутки и считать чистым» не существует. Наблюдение полезно только при работающем сборе событий, понятных правилах обнаружения и человеке, который действительно разбирает сигналы.

Сначала открываю доступ ограниченной группе и проверяю вход, документы, поиск и прикладные интеграции через каждый узел. Внешнюю публикацию включаю отдельным этапом; где возможно, использую шлюз с предварительной аутентификацией и закрываю прямой обход к SharePoint. Central Administration снаружи недоступна. Перед запуском оставляю дежурному конкретный порядок повторной изоляции: какие адреса закрывать, где смотреть события и кого привлекать. Технически восстановленный портал ещё нужно вернуть в управляемую эксплуатацию.

• Актуальные применимые исправления проверены на всех узлах, конфигурационный этап завершён.
• Подозрительные события разобраны; найденное закрепление устранено либо затронутые системы восстановлены.
• MachineKey обновлены и распространены, IIS перезапущен; другие раскрытые секреты отозваны отдельно.
• AMSI и антивирусная интеграция проверены, телеметрия поступает со всех узлов.
• Функции портала проверены, доступ ограничен необходимыми маршрутами, порядок повторной изоляции подготовлен.

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