Скрытый веб-шелл: методы обнаружения после компрометации сервера

Даже после устранения уязвимости и установки всех обновлений у злоумышленника может сохраниться контроль над сервером. Такое происходит, если в ходе атаки в веб-приложении остаётся веб-шелл — вредоносный скрипт, способный исполнять команды через HTTP-запросы.

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

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

Сущность веб-шелла

Обычная командная оболочка требует прямой авторизации на сервере через консоль или протокол удалённого управления. Веб-шелл же функционирует в контексте веб-приложения: сервер обрабатывает HTTP-запрос, вредоносный код извлекает команду, исполняет её с правами веб-процесса и отправляет результат атакующему.

В классификации ATT&CK веб-шеллы относятся к техникам закрепления доступа. Их задача — не первоначальный взлом, а сохранение контроля после компрометации. Уязвимость или украденные учётные данные дают злоумышленнику возможность проникнуть в систему, а веб-шелл позволяет возвращаться даже после устранения исходного вектора атаки.

Веб-шеллы могут иметь разную сложность. Простейшие версии исполняют одиночные команды или записывают файлы. Более продвинутые варианты включают файловый менеджер, доступ к СУБД, инструменты пересылки данных и проксирования соединений. Некоторые управляются специализированными клиентами, как например известный China Chopper.

Способы проникновения веб-шеллов

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

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

Однако не каждая загрузка файла позволяет разместить веб-шелл, а LFI-уязвимость не всегда приводит к RCE. Опасность возникает, когда приложение позволяет записывать исполняемый код в веб-каталоги, запускать внедрённые команды или использует скомпрометированные административные учётные данные.

• Удалённое исполнение команд. Эксплуатация уязвимости, позволяющей выполнить произвольный код и записать скрипт в директорию приложения.
• Файловая запись. Размещение исполняемого файла в каталоге, обрабатываемом веб-сервером как страница.
• Неконтролируемая загрузка. Принятие исполняемого кода под видом изображения, документа или архива с последующим запуском.
• Компрометация администратора. Использование легитимных функций управления для загрузки вредоносного компонента.
• Инфицированные модули. Вредоносное расширение, тема или обновление, содержащее скрытый функционал.

Возможности после успешной установки

Функциональность веб-шелла определяется правами веб-сервера. Если процесс работает с административными привилегиями, последствия могут распространиться на всю систему. Даже при ограниченных правах веб-процесс обычно имеет доступ к конфигурационным файлам, каталогам сайта, подключениям к базам данных и служебным секретам.

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

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

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

Примеры атак на Exchange и SharePoint

В 2021 году массовые атаки на локальные серверы Microsoft Exchange привлекли внимание к веб-шеллам. После эксплуатации уязвимостей злоумышленники размещали вредоносные веб-страницы, использовавшиеся для дальнейшего контроля. Компания Volexity, первой описавшая эту активность, зафиксировала выполнение команд и выгрузку почтовых данных через установленные веб-шеллы.

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