ToolShell — история пяти уязвимостей в Microsoft SharePoint

В течение 19 и 20 июля 2025 года несколько ИБ-компаний и национальных центров реагирования на инциденты опубликовали сообщения об активной эксплуатации локальных серверов SharePoint. Согласно их отчетам, злоумышленникам удалось обойти аутентификацию и получить полный контроль над зараженными серверами при помощи цепочки эксплойтов, использующей две уязвимости, CVE-2025-49704 и CVE-2025-49706, и получившей имя ToolShell. Помимо этого, в те же даты компания Microsoft выпустила внеочередные патчи для уязвимостей CVE-2025-53770 и CVE-2025-53771, позволяющих обходить исправления для CVE-2025-49704 и CVE-2025-49706. Выпуск этих новых, «правильных» обновлений привел к путанице по поводу того, какие именно уязвимости эксплуатируют атакующие и используют ли они эксплойты нулевого дня.

Продукты «Лаборатории Касперского» проактивно выявили и заблокировали вредоносную активность, связанную с этими атаками, что позволило нам собрать статистику о сроках и масштабах кампании. По нашим данным, повсеместная эксплуатация серверов SharePoint началась 18 июля. Под атаку попали серверы по всему миру, в том числе в Египте, Иордании, России, Вьетнаме и Замбии, а затронутые организации относились к различным отраслям, включая государственные и финансовые учреждения, сельское хозяйство, промышленность и лесоводство.

В ходе анализа артефактов, связанных с этими атаками, которые обнаружили наши продукты, а также информации, опубликованной другими исследователями, мы обнаружили дамп POST-запроса, который, по утверждениям, содержал вредоносную нагрузку, задействованную в этой кампании. Мы изучили его и убедились, что в нем действительно содержится детектируемая нашими технологиями полезная нагрузка. Более того, достаточно просто отправить этот запрос на уязвимый сервер SharePoint, чтобы она выполнилась на этом сервере.

Анализ эксплойта показал, что он действительно использует исправленные уязвимости CVE-2025-49704 и CVE-2025-49706, однако достаточно поменять в нем один байт, чтобы обойти патчи к ним.

В этой статье мы предоставим подробную информацию о CVE-2025-49704, CVE-2025-49706, CVE-2025-53770, CVE-2025-53771 и еще одной связанной с недавно выявленными эксплойтами уязвимости. Поскольку код эксплойта уже опубликован онлайн, несложен в использовании и представляет серьезную угрозу безопасности, мы рекомендуем организациям оперативно установить все необходимые обновления.

Эксплойт

Наше исследование началось с анализа дампа POST-запроса, связанного с волной атак на серверы SharePoint.

Фрагмент POST-запроса, эксплуатирующего уязвимые серверы

Как видно на скриншоте выше, POST-запрос адресован на путь /_layouts/15/ToolPane.aspx и включает два параметра: MSOtlPn_Uri и MSOtlPn_DWP. Если взглянуть на код ToolPane.aspx, можно увидеть, что сам по себе этот файл не содержит практически никакой функциональности и большая часть кода для него находится в классе ToolPane пространства имен Microsoft.SharePoint.WebPartPages в библиотеке Microsoft.SharePoint.dll. В свою очередь, в этом классе есть код, который работает с параметрами, используемыми в эксплойте. При этом при нормальных условиях получить доступ к ToolPane, не обойдя аутентификацию на атакованном сервере, нельзя. Здесь в игру включается уязвимость спуфинга сервера Microsoft SharePoint — CVE-2025-49706.

CVE-2025-49706

Эта уязвимость содержится в методе PostAuthenticateRequestHandler библиотеки Microsoft.SharePoint.dll. SharePoint требует, чтобы сервисы IIS (Internet Information Services) работали в режиме Integrated. В этом режиме объединяются этапы аутентификации в IIS и ASP.NET. Как следствие, результат аутентификации в IIS остается неопределенным до этапа PostAuthenticateRequest, на котором исполнены все методы аутентификации и в IIS, и в ASP.NET. В связи с этим метод PostAuthenticateRequestHandler использует набор флагов для отслеживания потенциальных нарушений при аутентификации. Логическая ошибка в этом методе позволяет обойти аутентификацию, если значение заголовка Referrer HTTP-запроса совпадает с /_layouts/SignOut.aspx, /_layouts/14/SignOut.aspx или /_layouts/15/SignOut.aspx (в любом регистре).

Уязвимый код в методе PostAuthenticateRequestHandler (Microsoft.SharePoint.dll версии 16.0.10417.20018)

Код на скриншоте выше обрабатывает запрос на выход из аккаунта и срабатывает в том числе, когда страница выхода указана в заголовке Referrer. Когда значение flag7 равно false, а значение flag6 — true, обходятся обе ветки условного перехода, которые потенциально могли бы выдать ошибку в связи с попыткой неавторизованного доступа.

Проверки на предмет неавторизованного доступа, которые обходит эксплойт

8 июля компания Microsoft выпустила обновление, исправляющее эту уязвимость. Для этого обновление вводит дополнительную проверку на использование пути ToolPane.aspx при наличии страницы выхода из аккаунта в заголовке Referrer.

Исправление CVE-2025-49706 (Microsoft.SharePoint.dll версии 16.0.10417.20027)

Эта проверка сравнивает окончание пути в запросе со строкой ToolPane.aspx в любом регистре. Можно ли ее обойти, например, используя другую конечную точку? Наш эксперимент показал, что не только можно, но и легко.

CVE-2025-53771

Нам удалось обойти патч CVE-2025-49706, добавив всего один байт к POST-запросу, выступающему в роли эксплойта. Все, что потребовалось — добавить символ / в конец пути к ToolPane.aspx.

Обход патча к CVE-2025-49706

В воскресенье 20 июля компания Microsoft выпустила обновление, закрывающее возможность обхода патча, которой присвоили идентификатор CVE-2025-53771. В этом исправлении проверка ToolPane.aspx заменена на проверку, есть ли путь, к которому обращается запрос, в списке разрешенных для использования совместно со страницей выхода из аккаунта в качестве источника ссылки (Referrer).

Исправление CVE-2025-53771 (Microsoft.SharePoint.dll версии 16.0.10417.20037)

В список разрешенных по умолчанию входят следующие пути: /_layouts/15/SignOut.aspx, /_layouts/15/1033/initstrings.js, /_layouts/15/init.js, /_layouts/15/theming.js, /ScriptResource.axd, /_layouts/15/blank.js, /ScriptResource.axd, /WebResource.axd, /_layouts/15/1033/styles/corev15.css, /_layouts/15/1033/styles/error.css, /_layouts/15/images/favicon.ico, /_layouts/15/1033/strings.js, /_layouts/15/core.js. Также администратор сервера может включать в него дополнительные пути.

В ходе экспериментов с обходом патча к CVE-2025-49706 с обновлениями от 8 июля, установленными на нашем отладочном стенде, мы получили неожиданный результат. Нам удалось не только обойти интересующее нас исправление, но и выполнить цепочку эксплойтов целиком! Но разве атакующие не использовали для этого дополнительную RCE-уязвимость CVE-2025-49704, которую должны были исправить в том же обновлении? Чтобы понять, почему у нас сработала вся цепочка эксплойтов, давайте взглянем на эту уязвимость и патч к ней.

CVE-2025-49704

CVE-2025-49704 — уязвимость десериализации недоверенных данных, связанная с некорректной валидацией XML-контента. Как мы уже упоминали, POST-запрос-эксплойт содержит два закодированных в URL параметра: MSOtlPn_Uri и MSOtlPn_DWP. Мы можем увидеть, как они обрабатываются, взглянув на код метода GetPartPreviewAndPropertiesFromMarkup библиотеки Microsoft.SharePoint.dll. Быстрый анализ показал, что MSOtlPn_Uri — это URL страницы, который может указывать на любой файл в директории CONTROLTEMPLATES, а в MSOtlPn_DWP находится нечто, известное как разметка WebPart. Эта разметка содержит специальные директивы, которые могут использоваться для выполнения безопасных элементов управления на сервере, и имеет формат, схожий с XML.

Разметка WebPart, использованная атакующими

Хотя «XML-код» в параметре MSOtlPn_DWP не содержит уязвимости сам по себе, он позволяет злоумышленникам создавать экземпляр элемента управления ExcelDataSet из Microsoft.PerformancePoint.Scorecards.Client.dll с вредоносной нагрузкой в свойстве CompressedDataTable и запускать его обработку с помощью метода получения свойства DataTable.

Код, который обрабатывает содержимое свойства CompressedDataTable элемента управления ExcelDataSet в методе получения свойства DataTable

Если взглянуть на код метода получения свойства DataTable элемента управления ExcelDataSet в Microsoft.PerformancePoint.Scorecards.Client.dll, можно обнаружить метод GetObjectFromCompressedBase64String, отвечающий за десериализацию значения свойства CompressedDataTable. Данные, полученные в виде строки в Base64, декодируются, распаковываются и передаются функции BinarySerialization.Deserialize из библиотеки Microsoft.SharePoint.dll.

DataSet с XML-контентом, эксплуатирующим CVE-2025-49704 (десериализованный)

Атакующие используют этот метод для отправки на уязвимый сервер вредоносного датасета, приведенного на скриншоте выше в десериализованном виде. Он содержит XML с элементом опасного типа System.Collections.Generic.List`1[[System.Data.Services.Internal.ExpandedWrapper`2[...], System.Data.Services, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089]], который позволяет атакующим выполнять произвольные методы при помощи хорошо известной техники ExpandedWrapper. Она нацелена на эксплуатацию небезопасной десериализации XML в приложениях на базе фреймворка .NET. По-хорошему, использование этой техники на SharePoint не должно быть возможно, поскольку BinarySerialization.Deserialize в Microsoft.SharePoint.dll использует XmlValidator, специально созданный, чтобы от нее защищать. Этот валидатор проверяет типы всех элементов в полученном XML и убеждается, что они есть в списке разрешенных. Эксплойт обходит эту проверку, добавляя объект ExpandedWrapper в список.

Теперь, чтобы выяснить, почему же эксплойт сработал на нашем отладочном стенде с установленными обновлениями от 8 июля 2025 года, давайте посмотрим, как исправили CVE-2025-49704. В соответствующем патче Microsoft не устраняет собственно уязвимость, а пытается снизить риски, добавив новый класс AddExcelDataSetToSafeControls в пространство имен Microsoft.SharePoint.Upgrade. Этот класс содержит новый код, который модифицирует файл web.config и помечает элемент управления Microsoft.PerformancePoint.Scorecards.ExcelDataSet как небезопасный. Поскольку SharePoint не выполняет этот код автоматически после установки обновлений, единственный способ добиться нужного результата — запустить обновление конфигурации вручную при помощи утилиты «Мастер настройки продуктов SharePoint». Стоит отметить, что в рекомендациях по безопасности, касающихся CVE-2025-49704, нет информации о необходимости этого шага, а значит, как минимум некоторые администраторы серверов SharePoint могут его не выполнить. При этом все, кто установил обновление, но не запустил апгрейд вручную, остаются уязвимыми к этой CVE.

CVE-2025-53770

20 июля компания Microsoft выпустила обновление с полноценным патчем к CVE-2025-49704. Он содержит обновленный XmlValidator, который правильно валидирует типы элементов в XML, таким образом предотвращая эксплуатацию этой уязвимости без ручного апгрейда конфигурации. Более того, он решает суть проблемы, лежащей в корне этой уязвимости, так что проэксплуатировать эту уязвимость через элементы управления, отличные от Microsoft.PerformancePoint.Scorecards.ExcelDataSet, также нельзя.

Код нового верификатора типа в обновленном XmlValidator

CVE-2020-1147

Читатели, знакомые с предыдущими эксплойтами для SharePoint, могут заметить, что уязвимость CVE-2025-49704/CVE-2025-53770 и эксплойт, использованный атакующими, похожи на более старую RCE-уязвимость CVE-2020-1147 во фреймворке .NET, SharePoint Server и Visual Studio. На самом деле, если сравнить эксплойты к CVE-2025-49704/CVE-2025-53770 и CVE-2020-1147, то можно увидеть, что код практически идентичен. Единственная разница в том, что в эксплойте для CVE-2025-49704/CVE-2025-53770 опасный объект ExpandedWrapper помещен в список. Таким образом, можно сказать, что CVE-2025-53770 — это вариант CVE-2020-1147, а патч к ней — обновленный патч к уязвимости 2020 года.

DataSet с XML-контентом, эксплуатирующим CVE-2020-1147

Заключение

Несмотря на то что патчи к уязвимостям ToolShell уже доступны, мы полагаем, что эта цепочка эксплойтов будет использоваться атакующими еще долго. Мы наблюдали подобную ситуацию с другими печально известными уязвимостями, такими как ProxyLogon, PrintNightmare или EternalBlue. Хотя их обнаружили несколько лет назад, некоторые злоумышленники до сих пор продолжают использовать их в атаках на непропатченные системы. Мы ожидаем, что та же судьба постигнет и ToolShell, поскольку эти уязвимости крайне просты в эксплуатации и позволяют получить полный контроль над уязвимым сервером.

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

Одновременно важно защищать сети организации от эксплойтов нулевого дня, которые могут использоваться, когда доступного патча к уязвимости еще нет. Для этого нужно использовать надежные защитные решения, способные блокировать подобные атаки. Так, преимущество будет у решения, которое отражало эксплойты ToolShell еще до того, как о них стало публично известно.

Kaspersky Endpoint Security использует технологии поведенческого анализа и проактивно защищает от эксплуатации описанных уязвимостей, а Kaspersky Endpoint Detection and Response (EDR) Expert может обнаружить как эксплуатацию, так и последующую вредоносную активность.

Обнаружение постэксплуатационной активности средствами Kaspersky Endpoint Detection and Response Expert

Еще одним барьером на пути подобных атак может служить межсетевой экран нового поколения, такой, как Kaspersky NGFW, который пополнит наше портфолио в ближайшее время.

Пример обнаружения атаки при помощи Kaspersky NGFW

Продукты «Лаборатории Касперского» детектируют эксплойты и вредоносное ПО, использованные в этих атаках со следующими вердиктами:

• UDS:DangerousObject.Multi.Generic
• PDM:Exploit.Win32.Generic
• PDM:Trojan.Win32.Generic
• HEUR:Trojan.MSIL.Agent.gen
• ASP.Agent.*
• PowerShell.Agent.*