Всем привет, в этой статье я покажу пошаговое руководство для решения практического задания для SOC с Letsdefend — SOC342 CVE‑2025‑53770 SharePoint ToolShell Auth Bypass and RCE. Само задание представляет собой эксплуатацию критической уязвимости, наша задача — понять, как началась атака, что делал злоумышленник и какие индикаторы компрометации есть.
Для начала надо понять, какие данные есть в самом оповещении.
Очень важно посмотреть и понять, что написано в RULE NAME: “CVE‑2025‑53770 SharePoint ToolShell Auth Bypass and RCE”, а также в Alert Trigger Reason: “Suspicious unauthenticated POST request targeting ToolPane.aspx with large payload size and spoofed referer indicative of CVE-2025-53770 exploitation”.
Тут размер(Content‑Length) полезной нагрузки тут очень большой, что не очень хорошо. Если посмотреть информацию о этой CVE, то можно найти версии, подверженные эксплуатации, нам же надо проверить, является ли наш сервер уязвимым
Скорее всего сервер уязвим (хотя мы не знаем точную версию, лучше предположить так)
В этой статье есть рекомендации, которые могут помочь найти попытки эксплуатации уязвимости:
Эти данные полностью совпадают с нашим алертом, в том числе Source IP Address. Ну и конечно, Device Action(это ответ от СЗИ) является Allowed, то есть запрос дошел до сервера(но это не ещё не значит, что само устройство скомпрометировано, потому что сервер мог только принять полезную нагрузку, но безопасно её обработать). Также можно посмотреть, является ли ip адрес плохим, это также можно сделать на вирустотал, 10 из 92 вендоров отмечают этот ip как плохой, но учитывая, что он упоминается в отчете про CVE‑2025‑53770 от CISA, его можно считать вредоносным.
Теперь надо узнать, действительно ли сервер взломан, для начала можно посмотреть сетевую активность, подтверждая, что запрос дошел:
Теперь можно посмотреть историю терминала.
Эта команда вызывает powershell.exe без загрузки профиля PowerShell (‑nop), без отображения окна консоли(‑w hidden), а ‑e означает, что последующий текст надо декодировать из base64 и выполнить. Вот декодированный текст:
Этот скрипт выводит всю информацию о криптографических ключах ASP.NET: если процесс удачен, то можно, например, подделывать ViewState, просто подписывая полезную нагрузку (и шифровать, если нужен decryptionKey) и из‑за этого удалённо выполнять код.
Если же найти в процессах эту команду powershell, то можно увидеть, что он имеет родителя w3wp.exe
w3wp.exe это процесс веб‑сервера IIS, который выполняет код на ASP.NET, PHP и других. Учитывая, что он создал процесс, уязвимость CVE‑2025‑53770 100% есть на сервере. Также, в Process User указан IIS APPPOOL\SharePoint — 80, который обычно имеет доступ к криптографическим данным, поэтому злоумышленник с высокой вероятностью их получил. Сервер можно считать скомпрометированным, надо его изолировать.
Теперь сервер изолирован. Смотрим, что ещё успел сделать злоумышленник.
Дальше он использует csc.exe (компилятор от Майкрософт), который превращает текстовые файлы с C# в исполняемые файлы(.exe) или библиотеки(.dll).
Следующее, что делает злоумышленник — это создает файл, который скачается и исполнится (а при исполнении он скачает файл payload.exe), когда пользователь перейдет на вкладку https://<TARGET_HOST>/_layouts/15/spinstall0.aspx. Делается это с помощью создания объекта ActiveX с clsid::ADB880A6-D8FF-11CF-9377-00AA003B7A11, это идентификатор класса для WScript.Shell, нужен, чтобы браузер выполнил или скачал файл в обход предупреждения безопасности.
Вот как видно эту команду в процессах:
Посмотрев хеш на VirusTotal, можно увидеть, что это ВПО.
Появление cmd.exe от родительского csc.exe является, с высокой вероятностью, вредоносным.
Скорее всего, файл, который был создан с помощью csc.exe и с помощью скачивания с сервера злоумышленника — являются одинаковыми, это просто способ, который позволит скачать полезную нагрузку, если 1 из методов не сработает. Либо эти файлы с одним названием, но для разных этапов атаки, к сожалению, узнать об этом без доступа к этим двум файлам нельзя.
Последняя команда нацелена на получение криптографических данных (как и первая команда).
Теперь можно заполнить детали инцидента
IOC’s:
Network:
1) 107.191.58.76 — вредоносный IP( С2, payload hosting)
2) POST запрос к /_layouts/15/ToolPane.aspx?DisplayMode=Edit&a=/ToolPane.aspx с Referer: /layouts/SignOut.aspx и большим размером содержимого
Хеши файлов(SHA-256):
3)10e01ce96889c7b4366cfa1e7d99759e4e2b6e5dfe378087d9e836b7278abfb6 — вредоносный код, полученный после декодирования base64 строки(на VirusTotal имеет имя machinekey.aspx)
4)92bb4ddb98eeaf11fc15bb32e71d0a63256a0ed826a03ba293ce3a8bf057a514 — вредоносный spinstall0.aspx
Пути файлов:
5) C:\Windows\Temp\payload.cs,
6) C:\Windows\Temp\payload.ехе,
7)C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\16\TEMPLATE\LAYOUTS\spinstall0.aspx
Цепочки процессов:
8) Процесс w3wp.exe создает powershell.exe с флагами «‑nop ‑w hidden ‑e»
9) powershell.exe → csc.exe во временной директории(C:\Windows\Temp)
10) w3wp.exe(4560) → powershell.exe(9876) → csc.exе(9901) → cmd.exe(9910) → powershell.exe(9920)
Необходимые действия после обнаружения атаки(в лабораторной работе мы просто изолируем сервер):
1) Заблокировать ip 107.191.58.76
2) Удалить файлы: C:\Windows\Temp\payload.cs, C:\Windows\Temp\payload.ехе, C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\16\TEMPLATE\LAYOUTS\spinstall0.aspx
3) Добавить sha-256 хеши в правила блокировки: 10e01ce96889c7b4366cfa1e7d99759e4e2b6e5dfe378087d9e836b7278abfb6 (это хеш кода, полученного из base64 строки) и 92bb4ddb98eeaf11fc15bb32e71d0a63256a0ed826a03ba293ce3a8bf057a514(файл из процесса 9910)
4) обновить сервер до безопасной версии
5) необходимо сменить криптографические ключи
Вот и закончился разбор этого критического инцидента. Вообще, я впервые пишу публичный разбор (обычно только для себя пишу) и хочу узнать ваше мнение об этой статье. Если что‑то было непонятно, то пишите, постараюсь ответить.
ссылка на оригинал статьи https://habr.com/ru/articles/1064082/