Storm-2603 спрятала вебшелл в памяти IIS через ToolShell. Что проверить на серверах с ASP.NET и Web Forms
5 ноября исследователи «Лаборатории Касперского» опубликовали разбор атаки группировки Storm-2603 на локальный SharePoint Server. Злоумышленники загрузили вебшелл прямо в среду выполнения ASP.NET внутри рабочего процесса IIS w3wp.exe и ни разу не записали его на диск. Вход был через давно закрытые уязвимости ToolShell, а приём с подменой VirtualPathProvider работает в любом приложении на классическом ASP.NET, включая сайты на Web Forms.
Для владельцев старых внутренних порталов вывод неприятный. Сервер на Windows Server 2016 с IIS, приложение на .NET Framework и Web Forms, ключи machineKey, не менявшиеся с запуска, — типичная картина, и именно такие системы становятся точкой входа. Если портал уже не получается нормально обновлять, а его код никто не знает целиком, честнее заложить в план разработку веб-приложения на поддерживаемом стеке и перенести на него функции по модулям, чем каждый год латать старую сборку. Ниже — что именно нашли исследователи и что проверить на своих серверах уже сейчас.
Что произошло
Отчёт опубликован в блоге Securelist, авторы — Александр Родченко и Родриго Вандерсон. Хронология такая: 20 декабря адрес жертвы отметился в сканере ONYPHE, три дня атакующие ничего не делали, а 24 декабря, в канун Рождества, провели полную цепочку удалённого выполнения кода. Инцидент обнаружили 26 декабря. После проникновения группировка поставила Velociraptor 0.73.4.0 (сам он уязвим, CVE-2025-6264), Zoho Assist, туннель VS Code CLI и Cloudflare Tunnel, затем попыталась отключить защиту и запустить шифровальщик Warlock. Запуск заблокировал модуль проактивной защиты.
Microsoft связывала Storm-2603 с ToolShell ещё летом 2025 года. В разборе Microsoft Security сказано, что уязвимы только локальные SharePoint Server 2016, 2019 и Subscription Edition, а SharePoint Online не затронут. Там же перечислены обязательные шаги после установки обновлений: включить AMSI в полном режиме, сменить ключи machineKey ASP.NET и перезапустить IIS на всех серверах фермы. Новый отчёт показывает, что серверы без этих шагов атакуют до сих пор.
Почему это касается любого сайта на ASP.NET
Сама уязвимость есть только в SharePoint, но закрепление в памяти построено на штатных механизмах ASP.NET на .NET Framework. Вебшелл зарегистрировал собственный VirtualPathProvider через непубличный метод класса HostingEnvironment. После этого среда выполнения отдаёт по нужным путям страницы, которых нет на диске: сканирование папок сайта ничего не находит, а вредонос живёт до перезапуска домена приложения. Повышение прав шло через SeImpersonatePrivilege, который есть у пула приложений IIS, по технике с именованными каналами EFSRPC. Итог — процессы с правами SYSTEM.
Второе общее место — machineKey. Им подписываются ViewState и cookie аутентификации форм. Если ключ украден, атакующий подделывает ViewState и снова выполняет код на сервере даже после установки патча. Поэтому Microsoft и требует менять ключи. В Web Forms ключ часто прописан прямо в web.config и одинаков на тестовом и боевом сервере. Как его вынести и включить проверку MAC, мы разбирали в материале о защите старого сайта на Web Forms.
# Кто зарегистрирован как VirtualPathProvider и какие сборки грузит w3wp.exe,
# смотрят по событиям ETW провайдера ASP.NET; для начала проверьте простое:
Get-ChildItem C:\inetpub -Recurse -Include *.aspx,*.ashx,*.asmx |
Where-Object LastWriteTime -gt (Get-Date).AddDays(-30)
Get-WebConfiguration -Filter system.web/machineKey -PSPath 'IIS:\Sites\Default Web Site'Что сделать сейчас
Отдельно составьте список серверов, где обновления ставить нельзя или страшно: старая ОС, приложение на .NET Framework 3.5, компоненты без поддержки. По Windows Server 2016 мы уже писали, что поддержка заканчивается 12 января 2027 года. Для таких систем стоит заранее выбрать путь: изоляция за обратным прокси, перенос на новый сервер или поэтапная миграция по нашему плану перехода с Web Forms на ASP.NET Core и Blazor. В ASP.NET Core нет ни VirtualPathProvider в прежнем виде, ни ViewState, так что этот класс атак туда не переносится.
Вопросы и ответы
Касается ли атака сайтов на ASP.NET Web Forms без SharePoint?
Сама уязвимость ToolShell есть только в локальном SharePoint Server 2016, 2019 и Subscription Edition. Но приём закрепления через VirtualPathProvider и подделку ViewState украденным machineKey работает в любом приложении на классическом ASP.NET. Если на сервере выполнили код через другую дыру, сайт на Web Forms можно заразить тем же способом.
Достаточно ли установить обновление SharePoint?
Нет. Microsoft требует после обновления сменить ключи machineKey ASP.NET и перезапустить IIS на всех серверах фермы. Если ключ уже украден, атакующий подделает ViewState и снова выполнит код, даже когда уязвимость закрыта.
Как найти бесфайловый вебшелл, если на диске ничего нет?
Смотреть на поведение w3wp.exe: дочерние процессы, неожиданные исходящие соединения, новые средства удалённого доступа. В отчёте Securelist предлагают сверять регистрации VirtualPathProvider с реальными файлами сайта по событиям ETW и искать сборки вида App_Web_toolpane.aspx. Перезапуск пула приложений удаляет вебшелл из памяти, но не закрывает вход.