The SOC Files 5: призрак в конвейере, или бесфайловый взлом SharePoint группой Storm-2603

Краткое содержание

В 2025 году несколько разных групп эксплуатировали уязвимости CVE-2025-53770 и CVE-2025-53771, известные как ToolShell, в локальных версиях Microsoft SharePoint с целью удаленного выполнения кода посредством специально сформированных HTTP-запросов. Одна из них после успешной эксплуатации уязвимости развернула в целевых системах шифровальщик. Как полагает Microsoft, за этой активностью стоит группа Storm-2603, которая ранее была замечена в использовании шифровальщиков, в отличие от других злоумышленников, нацеленных в основном на кражу учетных данных, шпионаж и эксфильтрацию данных.

В декабре ретроспективный анализ выявил активность, которая, по нашей оценке, соответствует тактикам, техникам и процедурам (TTP) группы Storm-2603. В рамках этой активности атакующий использовал рабочий процесс IIS в качестве моста к инфраструктуре заказчика в оперативной памяти, развернув механизмы доступа и управления в w3wp.exe без записи каких-либо данных на диск. Хотя постэксплуатационные действия оставили на диске определенные артефакты, этот «мост», обеспечивающий злоумышленникам доступ, продолжал работать исключительно в оперативной памяти.

Рассмотрим эту атаку подробнее.

Хронология атаки: стратегическая пауза и последующая эксплуатация

Атака разворачивалась в два этапа, с паузой между получением первичного доступа и последующей эксплуатацией уязвимостей. Хронология инцидента выглядит следующим образом.

• 20 декабря — проверка хоста на наличие уязвимости. На административную конечную точку SharePoint, связанную с компонентом ToolPane, был отправлен одиночный HTTP-запрос для проверки наличия уязвимости CVE-2025-53770.
• 21–23 декабря — тактическая пауза. За первичной проверкой последовало трехдневное затишье, отделившее ее от последующей вредоносной активности и снизившее вероятность оперативного обнаружения.
• 24 декабря — возобновление атаки с высокой интенсивностью. В канун Рождества, когда во многих компаниях дежурный состав ИБ-специалистов сокращен, злоумышленники запустили цепочку эксплойтов для удаленного выполнения кода (RCE) через рабочий процесс IIS (w3wp.exe) на конечной точке, которая ранее подверглась проверке.
• 26 декабря — обнаружение инцидента. Изначально трехдневная пауза помешала сопоставить разведывательный запрос от 20 декабря с последующей вредоносной активностью, в результате чего событию был присвоен низкий приоритет. Ретроспективный анализ установил, что проверочный запрос был начальной фазой последующего вторжения.

Фаза валидации первичного доступа

Проверка хоста на наличие уязвимости

Запрос от 20 декабря стал первым зафиксированным взаимодействием злоумышленников с целевым хостом. Он поступил из инфраструктуры, связанной с ONYPHE — интернет-платформой для определения поверхности атаки и управления ею, которая дает возможность выявлять доступные из Сети ресурсы, уязвимости и киберугрозы. В отличие от широко используемых инструментов, таких как Shodan и Censys, которые лишь предоставляют перечень доступных из интернета ресурсов, сопоставленный с публичными данными об известных уязвимостях, ONYPHE действительно проверяет, уязвима ли целевая система на самом деле.

Характеристики запроса соответствовали проверкам уязвимостей в ONYPHE, в которых используются активные неинвазивные запросы для выявления доступных из интернета систем, уязвимых к конкретным CVE. Для уязвимостей ToolShell ONYPHE применяет подход, разработанный Нильсом Хофмансом (Niels Hofmans, hazcod). В частности, платформа пытается внедрить в целевой сервер безвредный маркер, чтобы определить наличие уязвимости.

На этом этапе злоумышленники проверили возможность атаки на SharePoint по протоколу HTTP:

• целевая система обработала структурированные запросы через конвейер ASP.NET, не отклонив их;
• запрос достиг логики приложения, способной обрабатывать сериализованные данные;
• ни один защитный механизм не прервал и не изменил ход выполнения на границе приложения.

Примерно через двенадцать минут поступило второе входящее соединение из инфраструктуры, связанной с Pfcloud UG — провайдером, работающим по модели bulletproof-хостинга (BPH). С учетом временного фактора и истории сканирований и вредоносной активности с данного IP-адреса, можно предположить, что это соединение представляет собой последующую разведку в отношении вновь выявленной цели. На данном этапе попыток эксплуатации не было зафиксировано.
.

Этап активной эксплуатации: Санта забрал ваши данные и оставил открытым «черный ход»

Основная вредоносная активность имела место 24 декабря. Злоумышленники атаковали тот же SharePoint-хост, отправив специально сформированный запрос с IP-адреса 45.91.94.204 (45.91.92.0/22, ASN 63473, HostHatch, LLC). В результате внутри рабочего процесса IIS (w3wp.exe) был выполнен веб-шелл. Полезная нагрузка не записывалась на диск, а загружалась непосредственно в среду выполнения ASP.NET и участвовала в последующей обработке запросов. Имплант оставался в памяти на протяжении всего времени существования затронутого домена приложения. Состояние среды выполнения терялось при перезапуске пула приложений или IIS.

Источник атаки — узел SPN

IP-адрес 45.91.94.204 относится к сети Safing Privacy Network (SPN). SPN маршрутизирует каждое соединение через многослойный VPN-маршрут с несколькими узлами ретрансляции, что позволяет скрывать исходный IP-адрес.

SPN позиционируется как сеть, обеспечивающая повышенный уровень конфиденциальности интернет-трафика. По принципу работы инфраструктура SPN во многом схожа с Tor, однако имеет ряд отличий. Ключевые особенности SPN:

• скорость: близкая к VPN производительность, обеспечивающая высокую скорость передачи данных;
• поддержка сетевого уровня: поддержка разных протоколов, включая TCP, UDP и ICMP, в отличие от Tor, который в основном работает с TCP;
• маршрутизация на уровне приложений: прямое туннелирование трафика без использования браузера;
• множественные идентификаторы: одновременное использование нескольких выходных узлов для обхода ограничений на частоту запросов по IP-адресу;
• использование пакетов фиксированного размера и заполнения (padding), затрудняющих анализ сетевого трафика.

При этом сеть SPN менее распространена, чем Tor, и ее узлы зачастую не попадают в стандартные списки блокирования, применяемые к узлам Tor.

Архитектура веб-шелла

Веб-шелл, внедренный атакующими в среду выполнения w3wp.exe, представляет собой многомодульный фреймворк в оперативной памяти, выполнение которого оркеструется главным компонентом (G.cs) и расширяется за счет множества функциональных блоков в различных пространствах имен.

Реализация имеет модульную структуру проекта на C#, в которой каждая функциональная возможность выделена в отдельную единицу компиляции и динамически вызывается во время выполнения.

Компонент G.cs: управление конвейером обработки и взаимодействие с командным сервером

Управление конвейером обработки

Основным компонентом веб-шелла является файл G.cs. Он управляет контекстом выполнения, жизненным циклом импланта и сессиями, а также отвечает за взаимодействие с командным сервером.

Для закрепления в среде выполнения компонент G.cs выполняет следующие действия.

• Регистрирует пользовательского поставщика виртуальных путей (VirtualPathProvider) с помощью непубличного метода RegisterVirtualPassProviderInternal класса HostingEnvironment в ASP.NET, чтобы ASP.NET использовал его для обработки виртуальных путей. Этот поставщик автоматически добавляется в цепочку зарегистрированных поставщиков виртуальных путей.
  
• Передает управление политикой времени жизни объектов .NET Remoting предыдущему поставщику в цепочке, чтобы не нарушать существующее поведение жизненного цикла объектов.
  

Кроме того, для обхода средств защиты и обеспечения возможности регистрировать VirtualPathProvider даже в предварительно скомпилированном приложении, в AppDomain которого выполняется веб-шелл, модуль использует технику обхода механизмов контроля доверия (T1553):

• с помощью механизма рефлексии проверяет, является ли приложение предварительно скомпилированным;
• извлекает указатели на внутренние поля состояния класса BuildManager, отвечающего за управление компиляцией приложения, и модифицирует их во время выполнения;
  
• снова задействует механизм рефлексии для принудительного внедрения в среду выполнения.

Компонент G.cs использует функцию GetCacheKey() в качестве точки перехвата потока обработки виртуальных путей. Он обрабатывает входящие запросы к серверу SharePoint и анализирует их заголовки, отфильтровывая запросы злоумышленников.

Наличие специального значения User-Agent в заголовках запроса приводит к выполнению веб-шелла. Если запрос не соответствует этому условию, имплант остается в «спящем» состоянии, что затрудняет обнаружение его трафика.

Организация управления (транспорт в памяти)

В том же основном модуле (G.cs) прописана логика коммуникаций.

Вместо использования внешних фреймворков или стандартных маяков модуль применяет собственный бинарный протокол с XOR-обфускацией для обмена данными с командным сервером. Коммуникации вплетаются в обычный трафик приложения. С помощью хука GetCacheKey() модуль перехватывает стандартные HTTP-запросы. При обнаружении специфического значения User-Agent в заголовках запроса он парсит его, извлекает полезную нагрузку и при необходимости устанавливает TCP-соединение с целевым хостом в сети жертвы.

Чтобы обеспечить интерактивное управление, G.cs создает двунаправленный прокси-туннель, сохраняя активные целевые сокеты в оперативной памяти для объединения HTTP-каналов чтения и записи в пару.

Для организации промежуточного доступа (pivoting) и дальнейшего перемещения внутри сети предусмотрена поддержка TCP-соединений от командного сервера к произвольным хостам в целевой сети. Трафик проксируется через хост с установленным SharePoint.

Как видно на скриншотах, для проксирования трафика атакующие использовали инструмент suo5. По утверждению разработчиков, это надежный инструмент прямого проксирования (forward proxy) для сценариев, в которых исходящие соединения с интернетом запрещены.

Для повышения производительности G.cs изменяет параметры пула потоков (ThreadPool), увеличивая максимальное количество одновременно выполняемых операций и максимальное время ожидания.

Модуль Prog.cs: точка входа и диспетчер задач

Prog.cs — точка входа, которая принимает аргументы командной строки и передает их в модуль uk/London.cs. Тот выступает в роли оркестратора, отвечая за парсинг команд и повышение привилегий посредством имперсонации через именованные каналы. Мы подробнее рассмотрим его функциональность далее. При получении команды suo5 компонент London.cs внедряет основной модуль G.cs в среду выполнения ASP.NET, где тот функционирует как командная оболочка в памяти. После активации G.cs независимо обрабатывает входящий веб-трафик непосредственно в памяти процесса веб-сервера.

Модули взаимодействия с хостом

Следующие модули реализованы в виде отдельных компонентов и отвечают за прямое взаимодействие с системой. Они запускаются файлом London.cs при получении соответствующей команды от Prog.cs.

Модуль FileDownloader.cs

Модуль FileDownloader.cs загружает произвольные файлы с внешних URL-адресов, предоставленных командным сервером. Загруженные файлы сохраняются в каталоге ProgramData без участия пользователя.

Модуль LoggedOnUsers.cs

Этот модуль составляет список пользователей, вошедших в систему, и определяет типы их сессий (интерактивная, служебная или удаленная). Результаты сохраняются в оперативной памяти. Атакующие могут извлечь их с помощью функций проксирования и туннелирования, доступных в G.cs.

Модуль ProcessList.cs

Этот модуль выводит список запущенных процессов с указанием полных путей к соответствующим исполняемым файлам на диске. Результаты сохраняются в оперативной памяти. Атакующие могут извлечь их с помощью функций G.cs.

Модуль NetworkInfo.cs

Модуль извлекает информацию о текущих сетевых соединениях, включая используемые протоколы, локальные и удаленные IP-адреса и порты, а также состояние соединений. Он также перечисляет сетевые интерфейсы и их параметры. Результаты сохраняются в памяти и могут быть получены атакующими с помощью функций G.cs.

Модуль MSI.cs

Этот модуль скрытно устанавливает и выполняет пакеты MSI, предварительно загруженные с помощью FileDownloader.cs.

Модуль User.cs

Этот модуль отвечает за создание административных учетных записей через нативную подсистему SAM RPC (пространство имен SAMRPCNative) вместо стандартных инструментов командной строки. С его помощью, вероятно, атакующие стремились обойти средства обнаружения и обеспечить себе скрытый привилегированный доступ к целевым системам, сохраняющийся даже после завершения работы веб-шелла.

SAMRPCNative

Пространство имен SAMRPCNative содержит низкоуровневую C#-обертку P/Invoke для нативной библиотеки Windows samlib.dll и включает три подмодуля: SAMStructs.cs, SAMMethods.cs и SAMEnums.cs.

Подмодуль SAMEnums.cs

Реализует структурированные битовые перечисления и константные флаги, сопоставляющие числовые коды с их значениями безопасности в SAM, а также интерпретирует коды возврата системных операций.

Подмодуль SAMStructs.cs

Определяет нативные структуры данных, необходимые для корректного выравнивания данных в памяти при использовании P/Invoke и для маршалинга. Подмодуль отвечает за безопасное форматирование и выравнивание структур данных.

Подмодуль SAMMethods.cs

Содержит объявления внешних API (P/Invoke), импортированных из samlib.dll, для выполнения таких операций, как подключение к серверу SAM, создание учетных записей и открытие доменов.

Этот слой критически важен для атакующих, так как он позволяет осуществлять операции с учетными записями.

Повышение привилегий

Пространство имен uk содержит примитивы для эскалации привилегий. Чтобы повысить привилегии до уровня SYSTEM, используется техника имперсонации локального токена через интерфейс удаленного протокола шифрования файлов (EFSRPC), заимствованная из инструмента EfsPotato.

Эта функциональность реализована в классе uk/London. Он создает вредоносный именованный канал, после чего класс EfsrTiny, представляющий собой облегченную версию EfsPotato, подключается к RPC-серверу процесса LSASS.exe. Затем функция London.RpcThread вызывает функцию EfsRpcEncryptFileSrv из EfsrTiny, передавая ей специально сформированный путь \\localhost. Это заставляет LSASS.exe инициировать обратное подключение к именованному каналу злоумышленников. Наконец, функция London.Exp использует API >?ImpersonateNamedPipeClient, чтобы принудить процесс LSASS.exe к подключению и имперсонировать его токен, после чего запускает новый процесс с помощью CreateProcessAsUser с привилегиями SYSTEM. Поскольку веб-шелл выполняется из рабочего процесса IIS, он обладает привилегией SeImpersonatePrivilege, необходимой для реализации данной техники.

Пространство имен uk также содержит минималистичный слой MSRPC-клиента, построенный на явном определении таких структур, как RPC_CLIENT_INTERFACE и MIDL_STUB_DESC, что позволяет имитировать заглушку RPC-интерфейса. Это обеспечивает прямое взаимодействие со средой выполнения Windows RPC (Rpcrt4.dll) без использования заглушек, сгенерированных MIDL, или высокоуровневых RPC-абстракций. Такой подход предоставляет прямой контроль над процессами привязки (binding) и сериализации параметров (marshalling) в обход ограничений стандартных клиентских API.

Постэксплуатационная активность

Вскоре после внедрения веб-шелла скомпрометированный рабочий процесс запустил msiexec.exe для установки удаленной полезной нагрузки в формате MSI, размещенной в облачном хранилище Supabase. Этот MSI-файл оказался установщиком Velociraptor — инструмента с открытым исходным кодом для цифровой криминалистики и реагирования на инциденты (DFIR), а именно версии 0.73.4.0, уязвимой к CVE-2025-6264. Атакующие использовали ее для выполнения команд в целевой сети.

В октябре 2025 года Cisco Talos сообщила об использовании Velociraptor злоумышленниками в качестве фреймворка для выполнения операций на этапе после компрометации и связала эту активность с группой Storm-2603. Это многоцелевой инструмент, способный выполнять произвольные команды. В рассматриваемом случае он использовался для закрепления в системе, проведения разведки, сбора данных и запуска полезных нагрузок.

Злоумышленники развернули через Velociraptor несколько независимых механизмов туннелирования, включая Zoho Assist Unattended Support для несанкционированного удаленного доступа, туннелирование через VS Code CLI, Cloudflare Tunnel и легковесную утилиту обратного прокси. Таким образом они стремились сохранить доступ к системе даже в случае обнаружения и удаления части своего инструментария. На этом этапе злоумышленники уже не зависели от жизненного цикла рабочего процесса IIS и эксплуатации уязвимостей ToolShell.

Попытки нейтрализации EDR-решений

Получив доступ к целевой системе, злоумышленники смогли загрузить уязвимый драйвер, которым активно пользуются многие группы для завершения процессов EDR-решений. Нам удалось обнаружить основной драйвер по пути C:\ProgramData\rsndispot.sys (054a32d6033b1744dca7f49b2e466ea2). Кроме того, атакующие использовали вредоносную DLL-библиотеку (2d9ebf9c042f596f435865b40edad928) в рамках техники DLL sideloading. Это был модуль отключения процессов антивируса (AV killer) из состава вымогательского ПО Warlock. По всей видимости, он должен был завершить процессы защитных решений с помощью уязвимого драйвера rsndispot.sys.

Попытка развертывания программы-вымогателя

Атакующие попытались запустить программу-вымогатель в скомпрометированной системе. Однако модуль проактивной защиты в Kaspersky Endpoint Security заблокировал процесс шифровальщика, предотвратив потенциальный ущерб. Полученную вредоносную DLL мы идентифицировали как программу-вымогатель Warlock.

На что должна обращать внимание ИБ-команда

Артефакты десериализации ToolPane и CLR

Когда злоумышленники попытались получить доступ к ToolPane, в одном и том же домене приложения можно было наблюдать присутствие как динамически скомпилированной сборки App_Web_toolpane.aspx, так и вспомогательной сборки Microsoft.GeneratedCode.

Обе сборки могут применяться и в легитимных сценариях. Сборки App_Web_* генерируются при обычной компиляции страниц ASP.NET, а Microsoft.GeneratedCode, как правило, создается компонентом XmlSerializer в процессе легитимной сериализации данных. Однако запрос к конечной точке ToolPane, приводящий к немедленной загрузке Microsoft.GeneratedCode в рамках того же окна исполнения, указывает на то, что среда выполнения обрабатывает сериализованные данные, переданные в этом запросе.

Обнаружение эксплойта десериализации

Прежде всего, настоятельно рекомендуем ознакомиться с этой статьей, в которой рассматриваются методы, позволяющие выявлять попытки эксплуатации уязвимостей десериализации в CLR, а также приведены примеры YARA-правил и рекомендации по мониторингу. Ниже описывается базовая логика обнаружения.

Уязвимости десериализации следует рассматривать как специфический класс эксплойтов. В CLR десериализация — это не просто преобразование байтов в значения, а реконструкция графа объектов из входящего потока данных. Сериализацией и десериализацией занимаются форматтеры. Один из самых распространенных называется BinaryFormatter. Он работает с форматом NRBF, который представляет поток как последовательность записей, описывающих классы, массивы, примитивные значения и ссылки между объектами. Структура итогового графа зависит от данных, переданных в десериализатор. По сути, входящий поток определяет не только значения, но и конкретные типы объектов, связи между ними и этапы их жизненного цикла, которые среда выполнения должна материализовать.

Компания Microsoft прямо заявляет, что BinaryFormatter небезопасен и устранить связанные с ним риски невозможно. Начиная с .NET 9, его встроенная реализация фактически удалена из общего использования. Тем не менее Microsoft продолжает пользоваться BinaryFormatter в своих продуктах, том же SharePoint, поскольку он предоставляет широкие возможности и отличается простотой использования. Проблемы, связанные с BinaryFormatter, могут быть устранены только на уровне архитектуры. Аналогичные предупреждения Microsoft распространяет и на связанные небезопасные механизмы, включая LosFormatter, который использовался на уязвимой странице.

Основной риск небезопасной десериализации заключается в том, что CLR может разрешать непредусмотренные типы, создавать объекты в обход стандартных инвариантов конструктора и вызывать специальные механизмы жизненного цикла, такие как ISerializable, IObjectReference, IDeserializationCallback и методы, помеченные атрибутом [OnDeserialized]. Иными словами, заготовленные злоумышленником данные вынуждают среду выполнения построить граф объектов с типами, обработка которых чревата нежелательными побочными эффектами.

Эффективная стратегия обнаружения должна быть сосредоточена на артефактах построения графа объектов. Событиях загрузчика в CLR определяют релевантные сборки и домены приложений. Инспекция памяти и метаданных позволяет выявить имена типов и сгенерированные структуры сериализатора, связанные с потенциальной цепочкой гаджетов. В сценариях типа ToolShell небезопасная десериализация может приводить к созданию вспомогательных сборок (которые можно увидеть в событиях загрузчика) с метаданными, в которых содержатся полные имена типов (fully qualified type names), имена классов-гаджетов и строковые представления конкретизированных обобщенных типов (constructed generic types). Все это можно найти с помощью YARA. В нашем случае следует искать такие артефакты событий загрузчика, как Microsoft.GeneratedCode и App_Web_toolpane.aspx*, указывающие на сам факт десериализации, а также строки, идентифицирующие ObjectDataProvider, ExpandedWrapper и LosFormatter, которые свидетельствуют о десериализации входящего потока в потенциально опасные объекты. Обратите внимание, что вне контекста эти индикаторы не имеют особой значимости. Они лишь указывают на то, что среда выполнения получала входящие данные, потребовавшие генерации вспомогательного кода для реконструкции опасного графа объектов.

Гаджет-объекты, применяемые в эксплойтах для таких уязвимостей, как ToolShell, можно увидеть в сборниках инструментов наподобие ysoserial.net/YSoNet, в которых агрегированы известные цепочки гаджетов для небезопасной десериализации в .NET. С точки зрения информационной безопасности ценность этих проектов заключается не в их наступательных возможностях, а в каталогизации типов и структур, которые можно искать в потоках данных, оперативной памяти и вспомогательных сборках. Если любой из них встретился в памяти или во вспомогательной сборке, это следует рассматривать как серьезный индикатор эксплуатации.

Чтобы упростить обнаружение эксплуатируемых уязвимостей десериализации, мы создали инструмент CLRDeserializationExploitFinder. Он помогает выявлять попытки эксплуатации ToolShell, а также других цепочек гаджетов, представленных в ysoserial.net.

Обнаружение веб-шелла/импланта среды выполнения на базе VirtualPathProvider

Механизмы на основе VirtualPathProvider (VPP) следует рассматривать как отдельный класс бесфайловых имплантов среды выполнения. В ASP.NET метод HostingEnvironment.RegisterVirtualPathProvider регистрирует новый VPP в системе компиляции приложения. После регистрации приложение может загружать виртуальные пути в процессе динамической компиляции так, словно они указывают на обычные файлы на диске. Динамическая компиляция не требует, чтобы полезная нагрузка существовала в виде реального файла в файловой системе, и выполняется исключительно в пределах доверенной среды самого приложения. В процессе компиляции могут появляться временные файлы, но их нельзя рассматривать как надежные криминалистические артефакты. Поскольку VPP могут также использоваться в легитимных целях, выстраивание защиты следует начинать с инвентаризации разрешенных реализаций VPP. Регистрацию или использование любого нового VPP следует рассматривать как аномалию.

Чтобы понять, как работает динамическая генерация виртуальных страниц с использованием ASP.NET, IIS и CLR, а также как выявлять подобную активность, вы можете воспользоваться нашим проектом VirtualPathProvider Lab.

Самый полезный источник телеметрии для выявления этой техники — ETW-провайдер Microsoft-Windows-IIS-Configuration. Для обнаружения виртуальных путей основную ценность представляют события с ID 25 и 47. Событие с ID 25 фиксирует сопоставление ConfigPath и PhysicalPath, а событие с ID 47 — сопоставление конфигурационного пути с директорией. Если путь обслуживается VPP, эти события укажут на несоответствие: IIS и ASP.NET ведут себя так, словно путь имеет физическое представление, хотя на самом диске такого файла нет. В примере из VirtualPathProvider Lab это проявляется как сопоставление виртуального ресурса googlecheck.aspx с физическим путем, по которому реальный файл отсутствует. Расхождение между конфигурационным сопоставлением и фактическим состоянием файловой системы является одним из ключевых индикаторов виртуального содержимого.

Второй индикатор связан, скорее, с отсутствием ожидаемой телеметрии. Когда файлы физически есть на диске, IIS обычно формирует цепочку FileChangeNotificationMonitor, которая отражается в событиях с ID 17, 18, 19 и 21. В случае виртуальных путей, обслуживаемых пользовательским VirtualPathProvider, эта цепочка может отсутствовать либо отличаться от профиля обычного файла, поскольку физический объект и связанный с ним жизненный цикл изменений в файловой системе отсутствуют. Таким образом, сочетание положительных событий с ID 25 и 47 при одновременном отсутствии ожидаемых событий с ID 17/18/19/21 для того же пути формирует надежный паттерн детектирования: путь существует для IIS как ресурс, разрешенный в конфигурации, однако он не подкреплен файловой системой и не сопровождается стандартным мониторингом изменений файлов.

Подведем итог. При обнаружении следует искать несоответствие между тем, как IIS/ASP.NET сопоставляет ресурсы, и тем, что фактически присутствует на диске и отражается в телеметрии мониторинга изменений. Для известных приложений такие случаи можно отфильтровать по списку разрешенных легитимных реализаций VirtualPathProvider. Остальные случаи следует рассматривать как потенциальные импланты среды выполнения и дополнительно исследовать с помощью логов ETW, проверки файловой системы и анализа памяти процесса w3wp.exe.

Атрибуция

Microsoft отслеживает Storm-2603 как отдельную группу злоумышленников, не связанную с другими известными группами. Компания осторожно оценивает мотивацию группы, однако отмечает, что ранее Storm-2603 разворачивала программы-вымогатели Warlock и LockBit после активной эксплуатации уязвимостей в локальных версиях SharePoint. В проанализированном инциденте мы наблюдали аналогичную активность по эксплуатации SharePoint, а также модуль для нейтрализации EDR-решений, связанный с Warlock, и неудачные попытки запуска самого шифровальщика.

Согласно другим задокументированным инцидентам, Storm-2603 использует публичные уязвимости в почтовых шлюзах периметра для получения первоначального доступа с последующим развертыванием фреймворка Velociraptor с высокими привилегиями и установкой устойчивых зашифрованных туннелей с помощью коммерческого ПО для удаленного управления для проведения вторичного горизонтального перемещения. Это соответствует поведенческим паттернам на этапе после компрометации, которые мы наблюдали в нашем случае. В сочетании с эксплуатацией уязвимостей ToolShell это позволяет нам со средней степенью уверенности считать описываемый инцидент активностью группы Storm-2603.

Заключение

Главный урок из проанализированного в этой статье инцидента: компрометация доступного из интернета сервера SharePoint может привести к полностью бесфайловому выполнению кода непосредственно в доверенной среде приложения. Группа Storm-2603 обошлась без традиционного дроппера, закрепления посредством службы или открытой конечной точки для связи с командным сервером. Вместо этого злоумышленники развернули веб-шелл внутри процесса w3wp.exe, откуда могли координировать туннелирование, повышение привилегий, доступ к учетным данным и дальнейшее перемещение по сети. Обнаружение подобных угроз должно выходить за рамки поиска файловых веб-шеллов и фокусироваться на поведении среды выполнения: аномальной активности w3wp.exe, неожиданных исходящих соединениях, принуждении к аутентификации через RPC (RPC coercion), имперсонации токенов, а также появлении инструментов удаленного администрирования или DFIR после компрометации приложения.

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

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

• Trojan.MSIL.Agent.gen
• Trojan.Win64.DLLhijack.cdp

Индикатор компрометации

Индикатор компрометации	Описание
45.91.94[.]204	SPN-узел
0xFD91321BF7FF7245DDA9B7B5D791ACE8	vskp2 — имплант веб-шелла
hxxps://vdfccjpnedujhrzscjtq[.]supabase[.]co/storage/v1/object/public/image/v4[.]msi	Уязвимый пакет Velociraptor
0x3A55D8F8F29716C694671834D8C6CB29	C:\ProgramFiles\Velociraptor\Velociraptor.exe
hxxps://auth[.]qgtxtebl[.]workers[.]dev/	URL-адрес сервера Velociraptor
199.232.210[.]172	Ретранслятор трафика командного сервера
0x991EC6E04413F2D4D29341C17A8A54D5	Легитимный VS Code, использованный во вредоносных целях
0x3D553B9061C03F891CE97D7D2E64DDEE	Версия VS Code Insiders, использованная для создания туннеля
91.224.92[.]121	Командный сервер, размещенный на bulletproof-хостинге
49.51.132[.]100	SPN-узел
hxxps://github[.]com/cloudflare/cloudflared/releases/latest/download/cloudflared-windows-amd64[.]msi	Легитимная утилита туннелирования, использованная атакующими
0x2C32E44A013CBFC5A323EFB7694701D2	Исполняемый файл утилиты туннелирования
hxxps://files[.]catbox[.]moe/8f7vex[.]msi	URL-адрес для скачивания агента Zoho Assist Unattended, использованного злоумышленниками
0x112A86ECA3CB5A0B5E20AB744CC5AF93	Переименованный файл 7z.exe, необходимый для техники DLL sideloading
0xA930F81E3FB0A226EC5904D9043A17B8	C:\ProgramFiles(x86)\ZohoMeeting\UnAttended\ZohoMeeting.7z
204.76.203[.]219	Командный сервер, размещенный на bulletproof-хостинге
0x054a32d6033b1744dca7f49b2e466ea2	Уязвимый драйвер